From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Have we out-grown Flex? |
Date: | 2012-05-02 16:20:55 |
Message-ID: | CAMkU=1yKriHxhTQb2TP45-BiGN4V9OjQkV+h3c=Fy3BGNoF-fQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 1, 2012 at 5:53 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-05-02 16:25:20 | Re: smart shutdown at end of transaction (was: Default mode for shutdown) |
Previous Message | Tom Lane | 2012-05-02 16:19:04 | Re: clog double-dip in heap_hot_search_buffer |