From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
---|---|
To: | "'Zeugswetter Andreas SB'" <ZeugswetterA(at)wien(dot)spardat(dot)at>, The Hermit Hacker <scrappy(at)hub(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | RE: Plans for solving the VACUUM problem |
Date: | 2001-05-21 18:01:45 |
Message-ID: | 3705826352029646A3E91C53F7189E32016637@sectorbase2.sectorbase.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-21 18:07:28 | Re: Is stats update during COPY IN really a good idea? |
Previous Message | Bruce Momjian | 2001-05-21 17:56:37 | Re: Is stats update during COPY IN really a good idea? |