eviscerating the parser - Mailing list pgsql-hackers

From Robert Haas
Subject eviscerating the parser
Date
Msg-id BANLkTinsL9b_TycKw=n8XJDuYWHHSv6gOA@mail.gmail.com
Whole thread Raw
Responses Re: eviscerating the parser  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Just to see how much difference it would make, I tried ripping
everything out of the parser except for support for DML queries.  In
addition to removing the actual rules, I also yanked out most of the
unreserved keywords that are needed only for DML.  Results (pgbench -n
-S -T 300):

With patch:
tps = 10212.893052 (including connections establishing)
tps = 10213.012916 (excluding connections establishing)
tps = 10216.606402 (including connections establishing)
tps = 10216.722802 (excluding connections establishing)

Without patch:
tps = 10119.528987 (including connections establishing)
tps = 10119.642155 (excluding connections establishing)
tps = 10167.798764 (including connections establishing)
tps = 10167.900407 (excluding connections establishing)

This means that, in a situation where aren't using DML, and are
running very simple queries without prepared statements, the parser
bloat resulting from supporting all the other kinds of queries which
aren't being exercised by the tests results in a slowdown of
approximately 0.7%.

Patch is attached, in case anyone wants to play with it.  The size of
the generated parser is reduced by about two-third with this applied.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: inconvenient compression options in pg_basebackup
Next
From: Heikki Linnakangas
Date:
Subject: Re: ALTER TYPE DROP + composite-typed col vs. pg_upgrade