| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ANALYZE sampling is too good |
| Date: | 2013-12-09 21:20:17 |
| Message-ID: | 52A63411.7000504@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/6/13 3:21 AM, Andres Freund wrote:
> On 2013-12-05 17:52:34 -0800, Peter Geoghegan wrote:
>> Has anyone ever thought about opportunistic ANALYZE piggy-backing on
>> other full-table scans? That doesn't really help Greg, because his
>> complaint is mostly that a fresh ANALYZE is too expensive, but it
>> could be an interesting, albeit risky approach.
>
> What I've been thinking of is
>
> a) making it piggy back on scans vacuum is doing instead of doing
> separate ones all the time (if possible, analyze needs to be more
> frequent). Currently with quite some likelihood the cache will be gone
> again when revisiting.
FWIW, if synchronize_seqscans is on I'd think it'd be pretty easy to fire up a 2nd backend to do the ANALYZE portion (or perhaps use Robert's fancy new shared memory stuff).
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2013-12-09 21:24:31 | Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+ |
| Previous Message | Jeff Janes | 2013-12-09 21:18:59 | Re: ANALYZE sampling is too good |