eviscerating the parser

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: eviscerating the parser
Date: 2011-05-20 22:41:37
Message-ID: BANLkTinsL9b_TycKw=n8XJDuYWHHSv6gOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
eviscerate-parser.patch application/octet-stream 241.0 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei Kaigai 2011-05-21 01:50:11 Re: Error compiling sepgsql in PG9.1
Previous Message Peter Eisentraut 2011-05-20 21:45:18 Re: inconvenient compression options in pg_basebackup