Re: Have we out-grown Flex? - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Have we out-grown Flex?
Date
Msg-id CAMkU=1yKriHxhTQb2TP45-BiGN4V9OjQkV+h3c=Fy3BGNoF-fQ@mail.gmail.com
Whole thread Raw
In response to Have we out-grown Flex?  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Have we out-grown Flex?
Re: Have we out-grown Flex?
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: clog double-dip in heap_hot_search_buffer
Next
From: Bruce Momjian
Date:
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)