On Sat, May 28, 2011 at 5:51 PM, Jeff Janes 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 PostgreSQL Company
--
On Sun, May 22, 2011 at 3:10 PM, Robert Haas 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 different optimi
Robert Haas wrote:
> On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus 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.
> >
On Sun, May 22, 2011 at 1:38 PM, Joshua Berkus 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) evi
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 tho
On Sat, May 21, 2011 at 8:41 PM, Jeff Janes wrote:
> On Sat, May 21, 2011 at 5:31 PM, Robert Haas wrote:
>> On Sat, May 21, 2011 at 7:51 PM, Robert Haas wrote:
>>> Another point is that parsing overhead is quite obviously not the
>>> reason for the massive performance gap between one core runnin
On Sat, May 21, 2011 at 5:31 PM, Robert Haas wrote:
> On Sat, May 21, 2011 at 7:51 PM, Robert Haas 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 si
On Sat, May 21, 2011 at 8:36 PM, Kevin Grittner
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 Enterprise PostgreSQL Comp
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 7:51 PM, Robert Haas 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) eviscerat
On Sat, May 21, 2011 at 12:13 PM, Alvaro Herrera
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 resulting from support
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 exerc
12 matches
Mail list logo
