On Sat, Jun 01, 2013 at 09:22:05AM +0100, Simon Riggs wrote: > When would this make sense? > Frequently. Most of the time a tuple needs only one xid set. In most > cases, we set xmin and xmax a long time apart. Very few cases end with > both of them set inside the *same* xmin horizon. In a heavy > transactional enviroment, the horizon moves forwards quickly, on the > order of a few seconds. Very few rows get inserted and then > updated/deleted that quickly. With long reporting queries, data tends > to be updated less, so again the rows aren't touched within the same > horizon. As a result, we hardly ever need both xmin and xmax at the > same time - when we need to set xmax, xmin is already > committed/cleaned.
Is this really true? Consider a long running query A and a tuple created by B after A. If another transaction comes to update B you can't throw away the xmin because you need it to prove that A can't see the tuple. Or is the idea to create multixacts for each combination of xmin/xmax encountered? And the assumption is that there aren't that many? That could be measured. Have a nice day, -- Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
signature.asc
Description: Digital signature
