From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: UNDO and in-place update |
Date: | 2016-11-23 04:18:12 |
Message-ID: | 29874.1479874692@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)heroku(dot)com> writes:
> On Tue, Nov 22, 2016 at 7:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Oracle spends a lot of time on this, and it's really cache-inefficient
>> because the data is spread all over. This was what this guy felt in
>> circa 2001; I'd have to think that the cache unfriendliness problem is
>> much worse for modern hardware.
> I imagine that temporal locality helps a lot. Most snapshots will be
> interested in the same row version.
Yeah, but the problem is that all those transactions have to scavenge
through a big chunk of UNDO log to find out what they need to know.
Ultimately, I doubt that update-in-place buys much that we don't already
have with HOT updates (which postdate this old conversation, btw).
If you want MVCC semantics, you need to hold both versions of the tuple
*somewhere*. Oracle's solution is different from ours, but I'm not
exactly convinced that it's better. It makes some aspects better and
others worse.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-11-23 04:18:45 | Re: UNDO and in-place update |
Previous Message | Peter Geoghegan | 2016-11-23 04:02:30 | Re: UNDO and in-place update |