From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ashley Cambrell <ash(at)freaky-namuh(dot)com> |
Cc: | Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 7.3 schedule |
Date: | 2002-04-12 03:25:07 |
Message-ID: | 24184.1018581907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ashley Cambrell <ash(at)freaky-namuh(dot)com> writes:
> I remember an email Hannu sent (I originally thought Tome sent it but I
> found the email*) that said postgresql spends a lot of time parsing sql
> (compared to oracle), so if the BE/FE and libpq were extended to support
> pg_prepare / pg_bind, then it might make repetitive queries quicker.
I'm not sure I believe Hannu's numbers, but in any case they're fairly
irrelevant to the argument about whether a special protocol is useful.
He wasn't testing textually-long queries, but rather the planning
overhead, which is more or less independent of the length of any literal
constants involved (especially if they're not part of the WHERE clause).
Saving query plans via PREPARE seems quite sufficient, and appropriate,
to tackle the planner-overhead issue.
We do have some numbers suggesting that the per-character loop in the
lexer is slow enough to be a problem with very long literals. That is
the overhead that might be avoided with a special protocol.
However, it should be noted that (AFAIK) no one has spent any effort at
all on trying to make the lexer go faster. There is quite a bit of
material in the flex documentation about performance considerations ---
someone should take a look at it and see if we can get any wins by being
smarter, without having to introduce protocol changes.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hiroshi Inoue | 2002-04-12 03:58:01 | Re: 7.3 schedule |
Previous Message | Tom Lane | 2002-04-12 02:54:01 | Re: RFC: Restructuring pg_aggregate |