On Sun, May 22, 2011 at 3:10 PM, Robert Haas robertmh...@gmail.com wrote:
...
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
On Sat, May 28, 2011 at 5:51 PM, Jeff Janes jeff.ja...@gmail.com wrote:
But by both methods, the majority of the extra time that can be
accounted for is going to the planner.
Sounds like an argument for a plan cache.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Robert Haas wrote:
On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus j...@agliodbs.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
Robert,
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
On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus j...@agliodbs.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
Excerpts from Robert Haas's message of vie may 20 18:41:37 -0400 2011:
This means that, in a situation where aren't using DML, and are
running very simple queries without prepared statements, the parser
bloat resulting from supporting all the other kinds of queries which
aren't being
On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie may 20 18:41:37 -0400 2011:
This means that, in a situation where aren't using DML, and are
running very simple queries without prepared statements, the parser
bloat
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@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
Robert Haas wrote:
Incidentally, prepared transactions help a lot.
Prepared transactions or prepared statements?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, May 21, 2011 at 8:36 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas wrote:
Incidentally, prepared transactions help a lot.
Prepared transactions or prepared statements?
Uh, statements. -M prepared.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Sat, May 21, 2011 at 5:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@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 Sat, May 21, 2011 at 8:41 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Sat, May 21, 2011 at 5:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, May 21, 2011 at 7:51 PM, Robert Haas robertmh...@gmail.com wrote:
Another point is that parsing overhead is quite obviously not the
reason
12 matches
Mail list logo
