Re: eviscerating the parser

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: eviscerating the parser
Date: 2011-05-22 00:41:09
Message-ID: BANLkTinxWBjL=ZMxXFoDOhpKnTPRDicwNA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-05-22 00:50:20 Re: SSI predicate locking on heap -- tuple or row?
Previous Message Robert Haas 2011-05-22 00:39:36 Re: about EDITOR_LINENUMBER_SWITCH