From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Smith <gsmith(at)gregsmith(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: benchmarking the query planner |
Date: | 2008-12-12 18:02:34 |
Message-ID: | 7817.1229104954@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribi:
>> If you want ANALYZE to be cheap then you simply don't get to have a
>> trustworthy value of ndistinct.
> But then, maybe it's not all that critical that ANALYZE is cheap. For
> example, if we were to rework VACUUM ANALYZE so that on the same pass
> that VACUUM cleans each heap page, a callback is called on the page to
> grab the needed stats.
> Partial vacuum is a roadblock for this though :-(
Yeah --- now that partial vacuum is in, any argument that we can make
ANALYZE piggyback on VACUUM cheaply is dead anyway.
It would be interesting to consider "partial analyze" processing, but I
don't see how you would combine per-page partial results without a huge
increase in stats-related state data.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-12-12 18:05:57 | Re: WIP: default values for function parameters |
Previous Message | Greg Stark | 2008-12-12 18:01:40 | Re: benchmarking the query planner |