Simon Riggs wrote:
> On Thu, 2008-08-07 at 12:55 +0200, Jochem van Dieten wrote:
>> On Thu, Aug 7, 2008 at 12:38 PM, Simon Riggs wrote:
>>> I propose creating "Visibility Groups" that *explicitly* limit the
>>> ability of a transaction to access data outside its visibility group(s).
>> Doesn't every transaction need to access data from the catalogs?
>> Wouldn't the inclusion of a catalogs visibility group in every
>> transaction negate any potential benefits?
>
> True, but I don't see the catalogs as frequently updated data. The
> objective is to isolate frequently updated tables from long running
> statements that don't need to access them.
>
> Tables can be in multiple visibility groups, perhaps that wasn't clear.
> When we seek to vacuum a table, we take the lowest xmin of any group it
> was in when we took snapshot.
I'm not sure if "visibility group" is the best name for this - I had to
go away and think through what you meant about that last bit. Have I got
this right?
So - a "visibility group" is attached to a transaction.
My long-running transaction T0 can restrict itself to <catalogues> and
table "event_log".
Various other transactions T1..Tn make no promises about what they are
going to access. They all share the "null visibility group".
A table "user_emails" is in the "null visibility group" and can be
vacuumed based on whatever the lowest xid of T1..Tn is.
Table "event_log" is in both groups and can only be vacuumed based on
T0..Tn (presumably T0 is the oldest, since that's the point of the
exercise).
An attempt to write to user_emails by T0 will fail with an error.
An attempt to read from user_emails by T0 will be allowed?
What happens if I'm in ISOLATION LEVEL SERIALIZABLE? Presumably the read is disallowed then too?
-- Richard Huxton Archonet Ltd
