Re: eviscerating the parser

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: eviscerating the parser
Дата
Msg-id BANLkTi=+S_XojP4SF4EDsib8kO946JLgVQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: eviscerating the parser  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: eviscerating the parser
Re: eviscerating the parser
Список pgsql-hackers
On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
<alvherre@commandprompt.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


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: proposal: enhanced get diagnostics statement
Следующее
От: Dan Ports
Дата:
Сообщение: Re: SSI predicate locking on heap -- tuple or row?