RE: Plans for solving the VACUUM problem - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: Plans for solving the VACUUM problem
Date
Msg-id 3705826352029646A3E91C53F7189E32016637@sectorbase2.sectorbase.com
Whole thread Raw
In response to Plans for solving the VACUUM problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Plans for solving the VACUUM problem
Re: Plans for solving the VACUUM problem
List pgsql-hackers
> > My point is that we'll need in dynamic cleanup anyway and UNDO is
> > what should be implemented for dynamic cleanup of aborted changes.
> 
> I do not yet understand why you want to handle aborts different than
> outdated tuples.

Maybe because of aborted tuples have shorter Time-To-Live.
And probability to find pages for them in buffer pool is higher.

> The ratio in a well tuned system should well favor outdated tuples.
> If someone ever adds "dirty read" it is also not the case that it
> is guaranteed, that nobody accesses the tuple you currently want
> to undo. So I really miss to see the big difference.

It will not be guaranteed anyway as soon as we start removing
tuples without exclusive access to relation.

And, I cannot say that I would implement UNDO because of
1. (cleanup) OR 2. (savepoints) OR 4. (pg_log management)
but because of ALL of 1., 2., 4.

Vadim


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Is stats update during COPY IN really a good idea?
Next
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: Using 7.1rc1 under RH 6.2