From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: dependency between numbers keywords and parser speed |
Date: | 2011-03-15 06:19:44 |
Message-ID: | AANLkTinX8d8yf5z=_Mj2TV4qJ_Jxhi0J8fHgthJu6d_R@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Pavel
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2011-03-15 07:41:15 | Re: PostgreSQL 8.4 support on Windows 2008 R2 |
Previous Message | sanjay verma | 2011-03-15 05:03:05 | PostgreSQL 8.4 support on Windows 2008 R2 |