Re: eviscerating the parser

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: eviscerating the parser
Date: 2011-05-21 23:51:18
Message-ID: BANLkTi=+S_XojP4SF4EDsib8kO946JLgVQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Excerpts from Robert Haas's message of vie may 20 18:41:37 -0400 2011:
>> 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%.
>
> So the point here is, we do not need to worry about adding new keywords,
> because the performance impact is really minimal.  Right?

I think there are several possible points to be made here. I agree
that it's somewhat reassuring in that it certainly means that the
likely impact of any single keyword is probably minimal. On the other
hand, I wouldn't go so far as to say that we can add infinite numbers
of keywords with wild abandon: that's certainly not true, and spending
two or three minutes trying to use the existing ones rather than
adding new ones is probably time well spent. But on the flip side
there seems to be no reason for alarm about adding ~10
keywords/release or so, which I think is approximately what we've been
doing.

Another point is that parsing overhead is quite obviously not the
reason for the massive performance gap between one core running simple
selects on PostgreSQL and one core running simple selects on MySQL.
Even if I had (further) eviscerated the parser to cover only the
syntax those queries actually use, it wasn't going to buy more than a
couple points.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dan Ports 2011-05-22 00:09:58 Re: SSI predicate locking on heap -- tuple or row?
Previous Message Alvaro Herrera 2011-05-21 21:57:47 Re: proposal: enhanced get diagnostics statement