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

Re: Thoughts on statistics for continuously advancing columns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "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 16:16:45
Message-ID: 18031.1262189805@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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?

Well, the problem Josh has got is exactly that a constant high bound
doesn't work.

What I'm wondering about is why he finds that re-running ANALYZE
isn't an acceptable solution.  It's supposed to be a reasonably
cheap thing to do.

I think the cleanest solution to this would be to make ANALYZE
cheaper, perhaps by finding some way for it to work incrementally.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2009-12-30 16:20:08
Subject: Re: krb_server_keyfile setting doesn't work on Windows
Previous:From: Tom LaneDate: 2009-12-30 16:10:56
Subject: Re: krb_server_keyfile setting doesn't work on Windows

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