From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Mark Wong <markwkm(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Revisiting default_statistics_target |
Date: | 2009-06-07 15:08:27 |
Message-ID: | 1244387307.15799.47.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 2009-06-06 at 12:06 -0700, Josh Berkus wrote:
> > On the DL380 GB system, where I'm using a lot more drives the Jignesh,
> > I see a performance change of under 5%. 15651.14 notpm vs 16333.32
> > notpm. And this is after a bit of tuning, not sure how much the out
> > of the box experience changes on this system.
>
> Well, Jignesh and I identified two things which we think are "special"
> about DBT2: (1) it uses C stored procedures, and (2) we don't think it
> uses prepared plans.
If there is a performance regression it is almost certain to effect
planning; obviously if there is no planning there is no effect. But not
everybody can or wants to use prepared plans for a variety of reasons.
> I've been unable to reproduce any performance drop using pgbench.
I think we aren't likely to measure the effects accurately, since we are
unable to measure planning times with any sensible level of accuracy.
Increased planning times may not directly translate into performance
drops on many tests, though can still represent a problem for many
people.
If we can specify an accurate test mechanism, we may get some reasonable
information for decision making.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2009-06-07 15:41:08 | Re: pg_migrator issue with contrib |
Previous Message | Robert Haas | 2009-06-07 14:51:40 | Re: pg_migrator issue with contrib |