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: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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:56:31
Message-ID: 27200.1262192191@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Smith <greg(at)2ndquadrant(dot)com> writes:
> Right, and the only thing that makes this case less painful is that you 
> don't really need the stats to be updated quite as often in situations 
> with that much data.  If, say, your stats say there's 2B rows in the 
> table but there's actually 2.5B, that's a big error, but unlikely to 
> change the types of plans you get.  Once there's millions of distinct 
> values it's takes a big change for plans to shift, etc.

Normally, yeah.  I think Josh's problem is that he's got
performance-critical queries that are touching the "moving edge" of the
data set, and so the part of the stats that are relevant to them is
changing fast, even though in an overall sense the table contents might
not be changing much.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2009-12-30 16:59:40
Subject: Re: Thoughts on statistics for continuously advancing columns
Previous:From: Robert HaasDate: 2009-12-30 16:56:17
Subject: Re: KNNGiST for knn-search (WIP)

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