Re: [HACKERS] [PATCHES] The vacuum-ignore-vacuum patch
Alvaro Herrera [EMAIL PROTECTED] writes: Hannu Krossing asked me about his patch to ignore transactions running VACUUM LAZY in other vacuum transactions. I attach a version of the patch updated to the current sources. nonInVacuumXmin seems useless ... perhaps a vestige of some earlier version of the computation? In general, it seems to me that a transaction running lazy vacuum could be ignored for every purpose except truncating clog/subtrans. Since it will never insert its own XID into the database (note: VACUUM ANALYZE is run as two separate transactions, hence the pg_statistic rows inserted by ANALYZE are not a counterexample), there's no need for anyone to include it as running in their snapshots. So unless I'm missing something, this is a safe change for lazy vacuum, but perhaps not for full vacuum, which *does* put its XID into the database. 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. I think there was some discussion of doing that in connection with enlarging ANALYZE's sample greatly --- if ANALYZE goes back to being a full scan or nearly so, it'd sure be nice to combine it with the VACUUM scan. However maybe we should just accept that as the price of not having multiple vacuums interfere with each other. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] The vacuum-ignore-vacuum patch
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Hannu Krossing asked me about his patch to ignore transactions running VACUUM LAZY in other vacuum transactions. I attach a version of the patch updated to the current sources. nonInVacuumXmin seems useless ... perhaps a vestige of some earlier version of the computation? Hmm ... I remember removing a now-useless variable somewhere, but maybe this one escaped me. I don't have the code handy -- will check. In general, it seems to me that a transaction running lazy vacuum could be ignored for every purpose except truncating clog/subtrans. Since it will never insert its own XID into the database (note: VACUUM ANALYZE is run as two separate transactions, hence the pg_statistic rows inserted by ANALYZE are not a counterexample), there's no need for anyone to include it as running in their snapshots. So unless I'm missing something, this is a safe change for lazy vacuum, but perhaps not for full vacuum, which *does* put its XID into the database. But keep in mind that in the current code, clog truncation takes relminxid (actually datminxid) into account, not running transactions, so AFAICS this should affect anything. Subtrans truncation is different and it certainly should consider lazy vacuum's Xids. 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. I think there was some discussion of doing that in connection with enlarging ANALYZE's sample greatly --- if ANALYZE goes back to being a full scan or nearly so, it'd sure be nice to combine it with the VACUUM scan. However maybe we should just accept that as the price of not having multiple vacuums interfere with each other. 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? 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. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] The vacuum-ignore-vacuum patch
Alvaro Herrera [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
