Re: [PATCHES] Better default_statistics_target - Mailing list pgsql-hackers

From Greg Sabino Mullane
Subject Re: [PATCHES] Better default_statistics_target
Date
Msg-id ef95a1e9cc91b61000e72c2b941b0312@biglumber.com
Whole thread Raw
In response to Re: [PATCHES] Better default_statistics_target  ("Guillaume Smet" <guillaume.smet@gmail.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> As Tom stated it earlier, the ANALYZE slow down is far from being the
> only consequence. The planner will also have more work to do and
> that's the hard point IMHO.
>
> Without studying the impacts of this change on a large set of queries
> in different cases, it's quite hard to know for sure that it won't
> have a negative impact in a lot of cases.
>
> It's a bit too late in the cycle to change that IMHO, especially
> without any numbers.

The decision to add the magic "99/100" number was made without any
such analysis either, and I can assure you it has caused lots of real-world
problems. Going from 10 to 100 adds a small amount of planner overhead. The
99/100 change adds an order of magnitude speed difference to SELECT queries.
I still cannot see that as anything other than a major performance regression.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200802032259
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iD8DBQFHpo3jvJuQZxSWSsgRA61dAJ4hglXzi/EQT08j/NSWl8UeqI9CigCcDxSs
ob//pk7+jTCWPKlssAYKmy8=
=VKhG
-----END PGP SIGNATURE-----



pgsql-hackers by date:

Previous
From: rkalyankumar@aol.in
Date:
Subject: Reg: Question about concurrency/locking
Next
From: Tom Lane
Date:
Subject: Re: Reg: Question about concurrency/locking