From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Joshua Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: eviscerating the parser |
Date: | 2011-05-24 21:01:54 |
Message-ID: | 201105242101.p4OL1sP17152@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus <josh(at)agliodbs(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.
> >
> > I don't know if you say Jignesh's presentation, but there seems to be a lot of reason to believe that we are lock-bound on large numbers of concurrent read-only queries.
>
> I didn't see Jignesh's presentation, but I'd come to the same
> conclusion (with some help from Jeff Janes and others):
>
> http://archives.postgresql.org/pgsql-hackers/2010-11/msg01643.php
> http://archives.postgresql.org/pgsql-hackers/2010-11/msg01665.php
>
> We did also recently discuss how we might improve the behavior in this case:
>
> http://archives.postgresql.org/pgsql-hackers/2011-05/msg00787.php
>
> ...and ensuing discussion.
>
> However, in this case, there was only one client, so that's not the
> problem. I don't really see how to get a big win here. If we want to
> be 4x faster, we'd need to cut time per query by 75%. That might
> require 75 different optimizations averaging 1% a piece, most likely
> none of them trivial. I do confess I'm a bit confused as to why
> prepared statements help so much. That is increasing the throughput
> by 80%, which is equivalent to decreasing time per query by 45%. That
> is a surprisingly big number, and I'd like to better understand where
> all that time is going.
Prepared statements are pre-parsed/rewritten/planned, but I can't see
how decreasing the parser size would affect those other stages, and
certainly not 45%.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-05-24 21:03:41 | Re: 9.2 schedule |
Previous Message | Tom Lane | 2011-05-24 20:44:29 | Should partial dumps include extensions? |