From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Patches <pgsql-patches(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: The vacuum-ignore-vacuum patch |
Date: | 2006-07-24 18:39:12 |
Message-ID: | 12906.1153766352@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> A possible objection to this is that it would foreclose running VACUUM
>> and ANALYZE as a single transaction, exactly because of the point that
>> we couldn't insert pg_statistic rows using a lazy vacuum's XID.
> Hmm, what about having a single scan for both, and then starting a
> normal transaction just for the sake of inserting the pg_statistics
> tuple?
We could, but I think memory consumption would be the issue. VACUUM
wants a lotta memory for the dead-TIDs array, ANALYZE wants a lot for
its statistics gathering ... even more if it's trying to take a larger
sample than before. (This is probably why we kept them separate in
the last rewrite.)
> I think the interactions of Xids and vacuum and other stuff are starting
> to get complex; IMHO it warrants having a README.vacuum, or something.
Go for it ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-07-24 18:44:37 | Re: Making config file parser available to add-ins |
Previous Message | Peter Eisentraut | 2006-07-24 18:31:25 | Re: Making config file parser available to add-ins |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2006-07-24 19:48:03 | Re: [HACKERS] Resurrecting per-page cleaner for btree |
Previous Message | Joe Conway | 2006-07-24 18:19:54 | [Fwd: dblink patch - Asynchronous queries and parallel execution] |