-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
>
>>> 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 appea
"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
>
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 ze
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 t
>>> 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 boo
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 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
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
"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. Even
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
"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 mor
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 c
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 captur
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 a
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)
-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 shoul
17 matches
Mail list logo
