From: Greg Sabino Mullane <greg@turnstep.com>
To: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Thu, 12 Jun 2008 16:20:56 -0000
Message-ID: <f64390b17984f84f526285c89f126930@biglumber.com> (raw)
In-Reply-To: <484D6C1C.5070004@agliodbs.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> Also, I'd actually assert that "10" seems to be perfectly adequate for
> the majority of users. That is, the number of users where I've
> recommended increasing d_s_t for the whole database is smaller than the
> number where I don't, and of course we never hear from most users at
> all. So I'm pretty happy recommending "Leave the default. If you
> encounter problem queries, increase it to 100, and analyse the database.
Really? I'm the opposite: I never leave a client's setting at 10, that's
just asking for trouble. Making it 100 *after* you encounter problem
queries is reactive; I prefer being proactive. Nor is a setting of 10
"perfectly adequate": I think you might be the last person on the
lists who thinks so. That train has left the station, we've been trying
to decide what a better default should be other than 10, and, more to the
point, how to quantitatively measure it. The problem is, you really can't.
Sure, you can graph a tiny increase in ANALYZE time and disk space, but there
are no stock queries we can use to measure an increase in planning time.
Frankly, I'd be shocked if there is any significant difference and all
compared to the actual query run time.
The orders of magnitude speed up of certain queries when the d_s_t goes
above 98 is what spawned my original thread proposing a change to 100:
http://markmail.org/message/tun3a3juxlsyjbsw
While it's easy to get bogged down in theory about what things
d_s_t should measure, the optimal size of buckets, etc., it's still
a severe performance regression bug that should be fixed, IMO.
Changing the subject line as well: this is only tangentially related
to overhauling GUCS, although I'll point out again that this particular
config is a good example of one that needs more comments.
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200806121213
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkhRTKYACgkQvJuQZxSWSsjGvACeJkXZJ8cP385W9UXKzLHdzhvw
gqQAoJWdrepFbkxR2be7oetK8/o/yd9I
=w469
-----END PGP SIGNATURE-----
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: greg@turnstep.com
Subject: Re: Overhauling GUCS
In-Reply-To: <f64390b17984f84f526285c89f126930@biglumber.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox