Re: 7.3 schedule

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 7.3 schedule
Дата
Msg-id 24184.1018581907@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 7.3 schedule  (Ashley Cambrell <ash@freaky-namuh.com>)
Ответы Scanner performance (was Re: 7.3 schedule)  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RFC: Restructuring pg_aggregate
Следующее
От: Hiroshi Inoue
Дата:
Сообщение: Re: 7.3 schedule