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

Re: Thoughts on statistics for continuously advancing columns

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>,"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 17:13:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane escribió:
> 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.

Maybe only tangentially related: if this was a setup partitioned by a
timestamp, it would be very useful to be able to analyze only the
current partition and have updated stats for the parent relation as
well.  However AFAICT with your proposed changes in this area this would
not work, right?  You'd need an analyze on the parent relation, which is

Alvaro Herrera                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2009-12-30 17:16:41
Subject: Re: KNNGiST for knn-search (WIP)
Previous:From: Alvaro HerreraDate: 2009-12-30 17:05:00
Subject: Re: KNNGiST for knn-search (WIP)

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