Another idea Jan had today was whether we could vacuum more rows if a long-running backend is in serializable mode, like pg_dump.
--------------------------------------------------------------------------- Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> nonInVacuumXmin seems useless ... perhaps a vestige of some earlier > >> version of the computation? > > > Hmm, not useless at all really -- only a bug of mine. Turns out the > > notInVacuumXmin stuff is essential, so I put it back. > > Uh, why? > > > I noticed something however -- in calculating the OldestXmin we always > > consider all DBs, even though there is a parameter for skipping backends > > not in the current DB -- this is because the Xmin we store in PGPROC is > > always computed using all backends. The allDbs parameter only allows us > > to skip the Xid of a transaction running elsewhere, but this is not very > > helpful because the Xmin of transactions running in the local DB will > > include those foreign Xids. > > Yeah, this has been recognized for some time. However the overhead of > calculating local and global xmins in *every* transaction start is a > significant reason not to do 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 -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
