Re: eviscerating the parser - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: eviscerating the parser
Date
Msg-id BANLkTinxWBjL=ZMxXFoDOhpKnTPRDicwNA@mail.gmail.com
Whole thread Raw
In response to Re: eviscerating the parser  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: eviscerating the parser  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sat, May 21, 2011 at 5:31 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Sat, May 21, 2011 at 7:51 PM, Robert Haas <robertmhaas@gmail.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: about EDITOR_LINENUMBER_SWITCH
Next
From: "Kevin Grittner"
Date:
Subject: Re: SSI predicate locking on heap -- tuple or row?