Re: dependency between numbers keywords and parser speed

On Tue, Mar 15, 2011 at 2:19 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> 2011/3/15 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Mon, Mar 14, 2011 at 4:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>>>> there was a discussion about impact of number of keyword for parser
>>>> speed. I did some synthetic tests and I didn't see any slowness on
>>>> pgbench when I increased a number of keywords.
>>>
>>> I don't see any particular reason to suppose that pgbench would be a
>>> good framework for stressing parsing speed.  The queries it issues
>>> are of trivial length.
>>
>> I found that it was actually a fairly measurable component of the
>> select-only test when running with shared_buffers cranked up to a
>> reasonable value.  But it'd probably be a lot easier to measure on a
>> benchmark specifically targeted at the parser.
>>
>
> When I tested it - all data was in memory, there was a minimal (near
> zero IO) and I run read only test.
>
> It doesn't mean, so parser is gratis, but my numbers doesn't show any
> potential problem with 60 new keywords.

That's an interesting result, although it would be more interesting if
you posted the patch and benchmark methodology. It's important for us
not to overestimate the cost of adding keywords, and I don't object to
adding them where it adds meaningful clarity that is not otherwise
available or where it is necessary to comply with the SQL spec. But I
do think it is worth being disciplined about. We should think about
wording commands in a way that won't require new keywords; if there's
not a reasonable way to do it, then we add a keyword. Our preference
should be not to add keywords where that's reasonably possible.

It is particularly important for us to avoid keywords that are
partially or fully reserved. In that case, the issue is not parser
overhead but the fact that it breaks compatibility with previous
releases. pg_dump files can't be loaded, PL/pgsql procedures break,
and so on. I have been here and it isn't fun.

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