I think the big issue is that people think that if they have no one in a specific database, that VACUUM FULL will completely remove unused space, while this is not true if there are other backends connected to other databases.
This might be a stupid question, but why does one backend have to care about the global xmin at all? Isn't the local xmin the only important value? --------------------------------------------------------------------------- Tom Lane wrote: > Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > but after that it checks proc->xmin, where xmin may not be running on > > the same database. I wonder if this is correct or not. Maybe we should > > make sure that xmin is running on the same database > > How would you know? (At the time you are looking, it's quite possible > the other guy's xmin doesn't exist anymore.) In any case you can't just > arbitrarily ignore the other guy's xmin, since it's a proxy for > subsequent transaction IDs as well, and those might be in any database. > > It might be possible to do something by having each proc store both > a "local" and a "global" xmin computed as of its current xid start, > but I haven't really thought through the details. In any case, that > would be extra bookkeeping needed during every transaction start, > so I'd want to see proof of a generally-useful improvement in return. > > On the whole I'm against changing this logic ... I think the odds > of breaking something are high, and the odds of making a useful > improvement low ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
