Re: Revisiting default_statistics_target

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

In response to

Responses

Browse pgsql-hackers by date

  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