On Aug 7, 2008, at 9:49 AM, Robert Haas wrote:
This proposal sounds like it would target batch jobs, because those
are the kinds of jobs that where you can predict in advance what
tables will be needed. I don't know whether my personal set of
problems with MVCC syncs up with anyone else's, but
On Thu, Aug 07, 2008 at 01:30:27PM +0100, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly*
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By default, visibility_groups
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
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
Simon Riggs [EMAIL PROTECTED] writes:
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its
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
On Thu, 2008-08-07 at 13:30 +0100, Gregory Stark wrote:
Hm, so backing up a bit from the specific proposed interface, the key here is
being able to explicitly mark which tables your transaction will need in the
future?
Think of it as a promise to touch nothing except a specific set of
On Thu, 2008-08-07 at 14:18 +0100, Richard Huxton wrote:
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
Simon Riggs wrote:
Currently, we calculate a single OldestXmin across all snapshots on
the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility
group(s).
By
Simon Riggs wrote:
On Thu, 2008-08-07 at 14:18 +0100, Richard Huxton wrote:
An attempt to write to user_emails by T0 will fail with an error.
All above correct
The point of doing this is that *if* T0 becomes the oldest transaction
it will *not* interfere with removal of rows on user_emails.
Simon Riggs wrote:
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By
On Thu, 2008-08-07 at 10:20 -0400, Alvaro Herrera wrote:
Simon Riggs wrote:
Currently, we calculate a single OldestXmin across all snapshots on the
assumption that any transaction might access any table.
I propose creating Visibility Groups that *explicitly* limit the
ability of a
Simon Riggs [EMAIL PROTECTED] writes:
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By default, visibility_groups would be NULL, implying potential access
to all tables.
I think this would be a lot of
I think this would be a lot of mechanism and complication that will go
completely unused in the field. It'll be impossible even to explain let
alone to use effectively, for anyone who's not intensely steeped in the
details of MVCC.
+1.
This proposal sounds like it would target batch jobs,
Tom Lane [EMAIL PROTECTED] writes:
Simon Riggs [EMAIL PROTECTED] writes:
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By default, visibility_groups would be NULL, implying potential access
to all
Gregory Stark [EMAIL PROTECTED] writes:
I think Simon's interface was overly complex but if we can simplify it then it
could be useful. As Grittner mentioned implicit queries could make use of it
automatically. Also pg_dump or Slony could make use of it automatically.
Sorry implicit
Gregory Stark wrote:
I think Simon's interface was overly complex but if we can simplify it then it
could be useful. As Grittner mentioned implicit queries could make use of it
automatically. Also pg_dump or Slony could make use of it automatically.
Hmm, what use would it have for pg_dump?
On Thu, 2008-08-07 at 10:28 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I propose creating Visibility Groups that *explicitly* limit the
ability of a transaction to access data outside its visibility group(s).
By default, visibility_groups would be NULL, implying potential
Alvaro Herrera [EMAIL PROTECTED] writes:
Gregory Stark wrote:
I think Simon's interface was overly complex but if we can simplify it then
it
could be useful. As Grittner mentioned implicit queries could make use of it
automatically. Also pg_dump or Slony could make use of it automatically.
20 matches
Mail list logo
