Re: Revisiting default_statistics_target - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Revisiting default_statistics_target
Date
Msg-id 1244387307.15799.47.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Revisiting default_statistics_target  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Revisiting default_statistics_target  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: pg_migrator issue with contrib
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: pg_migrator issue with contrib