Re: eviscerating the parser

On Sat, May 21, 2011 at 8:41 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> On Sat, May 21, 2011 at 5:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sat, May 21, 2011 at 7:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> 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.
>>
>> Incidentally, prepared transactions help a lot.  On unpatched master,
>> with pgbench -T 300 -S -n:
>>
>> tps = 10106.900801 (including connections establishing)
>> tps = 10107.015951 (excluding connections establishing)
>
> Are you sure that you actually ran that with -M prepared?  The numbers
> look suspiciously similar to the ones reported in your original email.

That's without -M prepared; the subsequent number (~18K) is the one
with -M prepared. So prepared transactions increased throughput by
about 80%, in this test.

> For what it is worth, on my ancient hardware, the patched code is
> slower than the unpatched just as often as it is faster, using -n -S
> -T 300 on alternations between servers.

Well, that's pretty interesting. The effect *appeared* to be small
but consistent in my testing, but it could be I just got lucky; or the
choice of architecture and/or OS might matter.

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