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 <kleptog@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
