Re: Have we out-grown Flex?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Have we out-grown Flex?
Дата
Msg-id CAMkU=1yKriHxhTQb2TP45-BiGN4V9OjQkV+h3c=Fy3BGNoF-fQ@mail.gmail.com
обсуждение исходный текст
Ответ на Have we out-grown Flex?  (Peter Geoghegan <peter@2ndquadrant.com>)
Ответы Re: Have we out-grown Flex?  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: Have we out-grown Flex?  (james <james@mansionfamily.plus.com>)
Список pgsql-hackers
On Tue, May 1, 2012 at 5:53 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> Quite apart from the practical difficulties that we have with Flex
> (the fact that the authors are non-responsive and possibly retired,
> that annoying compiler warning, and the fact that we are forced to
> maintain our own Windows binaries of 2.5.35), it has some notable
> disadvantages. I am aware that the MySQL people use their own
> hand-coded lexical analyzer named sql_lex.cc, which provides a yacc
> interface, while avoiding using any lexical analyzer generator
> whatsoever. They can't have done this just for fun, and no doubt this
> goes some way to explaining their continued performance advantage for
> very simple queries. I have heard people complain about Postgres
> parser overhead for "pgbench -S" style use-cases where it is
> unreasonably high, and I've heard them do so more than once.

For -S -M simple, the time spent planning is 5 times more than the
time spent parsing.  It may be worthwhile to reduce the time spent
parsing, but if the goal is parity with MySQL it probably isn't the
place to start.

(If you use a bottom-up profiler, the time spent in planning is
scattered over so many different functions that none of them look very
important individually)

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: clog double-dip in heap_hot_search_buffer
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: smart shutdown at end of transaction (was: Default mode for shutdown)