Skip site navigation (1) Skip section navigation (2)

Re: Have we out-grown Flex?

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-05-02 16:25:20
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Previous:From: Tom LaneDate: 2012-05-02 16:19:04
Subject: Re: clog double-dip in heap_hot_search_buffer

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group