-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
Kevin Grittner [EMAIL PROTECTED] writes:
On Thu, Jan 31, 2008 at 10:19 PM, in message
[EMAIL PROTECTED], Robert Treat
[EMAIL PROTECTED] wrote:
Bad plans from boosting to 100 or less? Or something much higher?
I boosted on a large number of columns based on domains. County
number columns
On Thu, Jan 31, 2008 at 10:19 PM, in message
[EMAIL PROTECTED], Robert Treat
[EMAIL PROTECTED] wrote:
On Thursday 31 January 2008 09:55, Kevin Grittner wrote:
I can confirm that I have had performance tank because of boosting
the statistics target for selected columns. It appeared to be
Decibel! escribió:
BTW, with autovacuum I don't really see why we should care about how
long analyze takes, though perhaps it should have a throttle ala
vacuum_cost_delay.
Analyze already has vacuum delay points (i.e. it is already throttled).
--
Alvaro Herrera
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can confirm that I have had performance tank because of boosting
the
Kevin Grittner wrote:
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can confirm that I have had performance tank
On Thursday 31 January 2008 09:55, Kevin Grittner wrote:
On Wed, Jan 30, 2008 at 8:13 PM, in message
[EMAIL PROTECTED], Christopher
Browne [EMAIL PROTECTED] wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
I can
On Mon, Jan 28, 2008 at 11:14:05PM +, Christopher Browne wrote:
On Dec 6, 2007 6:28 PM, Decibel! [EMAIL PROTECTED] wrote:
FWIW, I've never seen anything but a performance increase or no change
when going from 10 to 100. In most cases there's a noticeable
improvement since it's common to
Decibel! [EMAIL PROTECTED] writes:
I think that before doing any of that you'd be much better off
investigating how much performance penalty there is for maxing out
default_statistict_target. If, as I suspect, it's essentially 0 on
modern hardware, then I don't think it's worth any more
On Jan 31, 2008 12:08 AM, Gregory Stark [EMAIL PROTECTED] wrote:
Decibel! [EMAIL PROTECTED] writes:
I think that before doing any of that you'd be much better off
investigating how much performance penalty there is for maxing out
default_statistict_target. If, as I suspect, it's
Guillaume Smet [EMAIL PROTECTED] writes:
On Jan 31, 2008 12:08 AM, Gregory Stark [EMAIL PROTECTED] wrote:
That's not my experience. Even just raising it to 100 multiplies the number
of
rows ANALYZE has to read by 10. And the arrays for every column become ten
times larger. Eventually they
On Jan 30, 2008 5:58 PM, Decibel! [EMAIL PROTECTED] wrote:
On Mon, Jan 28, 2008 at 11:14:05PM +, Christopher Browne wrote:
On Dec 6, 2007 6:28 PM, Decibel! [EMAIL PROTECTED] wrote:
FWIW, I've never seen anything but a performance increase or no change
when going from 10 to 100. In
On Wed, Jan 30, 2008 at 09:13:37PM -0500, Christopher Browne wrote:
There seems to be *plenty* of evidence out there that the performance
penalty would NOT be essentially zero.
Tom points out:
eqjoinsel(), for one, is O(N^2) in the number of MCV values kept.
It seems to me that there
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 Dec 6, 2007 6:28 PM, Decibel! [EMAIL PROTECTED] wrote:
FWIW, I've never seen anything but a performance increase or no change
when going from 10 to 100. In most cases there's a noticeable
improvement since it's common to have over 100k rows in a table, and
there's just no way to capture any
-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)
17 matches
Mail list logo
