Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> ... but we won't come out ahead unless advancing xmin > >> intra-transaction really helps, and I'm not sure I believe that (except > >> in the special case of VACUUM, and we already have a solution for that, > >> which would be independent of this). > > > The improvement is going to be a win for multi-statement transactions > > --- the only question is how often are they long-running. > > Uh, no, that's not very clear. A long-running transaction will be a > VACUUM bottleneck because of its own XID, never mind its xmin. To make > this helpful, you have to posit a lot of overlapping long-running > transactions (such that the distance back to GlobalXmin might average > about twice the distance back to the oldest live XID). That's not > impossible but I wonder whether it's not mostly a token of bad > application design.
Well, my secondary addition was to start MyProc->xmin with the current xid counter, rather than your own xid. This is because your xid is already in progress and so will not be touched, so why not start with the current xid counter. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us 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
