-----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-----
