eviscerating the parser

Поиск
Список
Период
Сортировка
От Robert Haas
Тема eviscerating the parser
Дата
Msg-id BANLkTinsL9b_TycKw=n8XJDuYWHHSv6gOA@mail.gmail.com
обсуждение исходный текст
Ответы Re: eviscerating the parser
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: inconvenient compression options in pg_basebackup
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: ALTER TYPE DROP + composite-typed col vs. pg_upgrade