From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-22 18:19:15 |
Message-ID: | 2001.1151000355@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> The Oracle design has got other drawbacks: if you need to access a row
>> version other than than the very latest, you need to go searching in the
>> rollback segments for it. This is slow (no index help)
> Just for the record, if i understood correctly -- this was all a bit black
> magicky -- Oracle found the data in the rollback segment by storing a pointer
> to it in the block header where the updated data is. Ie, it could jump
> straight to the right place.
Yeah, you should be able to find the older version easily enough, if you
arrived at the newer version and realized you needed to visit the older
version. But this fails in scenarios where you are searching on a
column that's been updated --- the index entry for the newer version
will not lead you to visit it at all. I've not seen any documentation
about what Oracle does with cases like that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2006-06-22 18:23:15 | Re: vacuum, performance, and MVCC |
Previous Message | Josh Berkus | 2006-06-22 18:10:45 | Re: [CORE] GPL Source and Copyright Questions |