Re: Thoughts on statistics for continuously advancing columns - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Thoughts on statistics for continuously advancing columns
Date
Msg-id 4B3B247D020000250002DA9A@gw.wicourts.gov
Whole thread Raw
In response to Re: Thoughts on statistics for continuously advancing columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Thoughts on statistics for continuously advancing columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@agliodbs.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


pgsql-hackers by date:

Previous
From: "Hiroshi Saito"
Date:
Subject: Re: test/example does not support win32.
Next
From: Andrew Dunstan
Date:
Subject: Re: test/example does not support win32.