Skip site navigation (1) Skip section navigation (2)

Re: Thoughts on statistics for continuously advancing columns

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Josh Berkus" <josh(at)agliodbs(dot)com>,"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Nathan Boley" <npboley(at)gmail(dot)com>,<pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Thoughts on statistics for continuously advancing columns
Date: 2009-12-30 15:59:25
Message-ID: 4B3B247D020000250002DA9A@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> My thoughts on dealing with this intelligently without a major
>> change to statstics gathering went along these lines:
> 
>> 1. add columns to pg_statistic to hold estimates of upper and
>> lower bounds growth between analyzes.
> 
> This seems like a fundamentally broken approach
 
> I don't have a better idea at the moment :-(
 
It's been a while since I've been bitten by this issue -- the last
time was under Sybase.  The Sybase suggestion was to either add
"dummy rows" [YUCK!] to set the extreme bounds or to "lie to the
optimizer" by fudging the statistics after each generation.  Perhaps
we could do better by adding columns for high and low bounds to
pg_statistic.  These would not be set by ANALYZE, but
user-modifiable to cover exactly this problem?  NULL would mean
current behavior?
 
-Kevin

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-12-30 16:05:36
Subject: Re: test/example does not support win32.
Previous:From: Hiroshi SaitoDate: 2009-12-30 15:57:09
Subject: Re: test/example does not support win32.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group