-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
On Wed, Dec 05, 2007 at 06:49:00PM +0100, Guillaume Smet wrote:
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
there a reason not to make this change? I know I've been lazy and not run
any absolute
On Wed, 2007-12-05 at 15:13 -0500, Chris Browne wrote:
I have the theory (thus far not borne out by any numbers) that it
might be a useful approach to try to go through the DB schema and use
what information is there to try to come up with better numbers on a
per-column basis.
Yeh, agreed.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Simon spoke:
The choice of 100 is because of the way the LIKE estimator is
configured. Greg is not suggesting he measured it and found 100 to be
best, he is saying that the LIKE operator is hard-coded at 100 and so
the stats_target should
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
there a reason not to make this change? I know I've been lazy and not run
any absolute figures, but rough tests show that raising it (from 10 to
100)
[EMAIL PROTECTED] (Guillaume Smet) writes:
On Dec 5, 2007 3:26 PM, Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Agreed, this would be a nice 8.4 thing. But what about 8.3 and 8.2? Is
there a reason not to make this change? I know I've been lazy and not run
any absolute figures, but rough tests
Chris Browne [EMAIL PROTECTED] writes:
- Any columns marked unique could keep to having somewhat smaller
numbers of bins in the histogram because we know that uniqueness
will keep values dispersed at least somewhat.
I think you're on the wrong track. It's not dispersal that's
Hi,
- why did we pick 100 for the LIKE operator?
http://archives.postgresql.org/pgsql-hackers/2006-09/msg01715.php
- should we document the better selectivity for LIKE operators at 100?
Probably... it I'm the only one who knows about it ;)
--
Matteo Beccati
Openads -
Simon Riggs [EMAIL PROTECTED] writes:
Long text fields that might use LIKE should be set to 100. CHAR(1) and
general fields should be set to 10.
I could see arguing that either way. Longer fields are capable of more
precision and so may need more buckets to predict. On the other hand longer
On Wed, 2007-11-14 at 00:00 -0500, Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Per a recent bug in which the planner can behave very differently at
100, and accounting for the fact that analyze is still plenty fast on
today's systems even at a tenfold increase, attached
Per a recent bug in which the planner can behave very differently at
100, and accounting for the fact that analyze is still plenty fast on
today's systems even at a tenfold increase, attached is a patch to
change default_statistics_target from 10 to 100.
Index: doc/src/sgml/config.sgml
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Per a recent bug in which the planner can behave very differently at
100, and accounting for the fact that analyze is still plenty fast on
today's systems even at a tenfold increase, attached is a patch to
change default_statistics_target from 10
12 matches
Mail list logo
