Re: UNDO and in-place update - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: UNDO and in-place update
Date
Msg-id CAM3SWZRSXUq=2SRsXonJKD6v6met+g6OP6QnVQfyU8NkY0+ECg@mail.gmail.com
Whole thread Raw
In response to Re: UNDO and in-place update  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: UNDO and in-place update  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: UNDO and in-place update  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Tue, Nov 22, 2016 at 8:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I agree that HOT is roughly as effective, at least when you get mostly
HOT updates.

I think that there is an under-appreciated issue with index bloat and
VACUUM. Bloat in the sense of a B-Tree becoming unbalanced. I think
that short term bursts of non-HOT updates bloat the *keyspace* of
B-Trees, making them unbalanced. A short term burst (possibly
associated with one long running transaction that prevents pruning)
can cause long term damage to the key space.

The best thing by far about an alternative design like this is that it
performs *consistently*. I believe that we will lose on real-world
cases that play to the strengths of the current design. That doesn't
mean that it isn't worth it, but it does make it exceptional
difficult.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: UNDO and in-place update
Next
From: Tom Lane
Date:
Subject: Re: UNDO and in-place update