Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
>> Tom Lane wrote:
>>>> Another real problem with doing pruning only in UPDATE path is that
>>>> we may end up with long HOT chains if the page does not receive a
>>>> UPDATE, after many consecutive HOT updates.
>>> How is that, if the same number of prune attempts would occur?
>
>> It wouldn't. To avoid the long HOT chains, we want to prune more often
>> than what's needed to just make room for updates.
>
> I don't follow. HOT chains can only get longer by updates.
Yes. We don't seem to be on the same wavelength...
Imagine a page with just one tuple on it:
1
After a bunch of updates, it looks like this
1 -> 2 -> 3 -> 4 -> 5
1 is the tuple the indexes point to, others are heap only.
Every time you do an index lookup, you have to follow that chain from 1
to 5. Which gets expensive. That's why we want to prune the chain to
make it shorter, even if there's still plenty of room on the page for
updates, and even if we're never going to update it again.
That's the theory. I don't know *how* expensive following the chain
really is, compared to index scans skipping over entries marked as
killed. I don't remember seeing any measurements of that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
