Re: 7.3 schedule - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 7.3 schedule
Date
Msg-id 24184.1018581907@sss.pgh.pa.us
Whole thread Raw
In response to Re: 7.3 schedule  (Ashley Cambrell <ash@freaky-namuh.com>)
Responses Scanner performance (was Re: 7.3 schedule)
List pgsql-hackers
Ashley Cambrell <ash@freaky-namuh.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: RFC: Restructuring pg_aggregate
Next
From: Hiroshi Inoue
Date:
Subject: Re: 7.3 schedule