From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Nathan Boley <npboley(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, "jd(at)commandprompt(dot)com" <jd(at)commandprompt(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(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:11:42 |
Message-ID: | 7953.1229105502@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:
> Is there any way to "merge" the statistics? i.e. if a full table scan
> is done to compute precise statistics, and later a regular analyze scan
> is done, then perhaps instead of clobbering the previous stats, you
> merge them with the new ones, thus not completely losing those previous
> ones.
Seems like a pretty hard problem unless you store a whole lot more
statistics state than we do now (which of course would create its own
costs). How would you know which portion of the old stats to not
believe anymore?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-12-12 18:15:00 | Re: benchmarking the query planner |
Previous Message | Tom Lane | 2008-12-12 18:10:00 | Re: benchmarking the query planner |