From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Combo xids |
Date: | 2013-06-01 09:37:02 |
Message-ID: | 20130601093701.GA30050@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | javadi | 2013-06-01 09:41:13 | Question about storage subsystem of PotgreSQL |
Previous Message | Fabien COELHO | 2013-06-01 09:00:27 | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |