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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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