Bruce Momjian <bruce@momjian.us> writes:
> Simon Riggs wrote:
>> The speed/cost is the same. The issue is *when* we do this. Normal
>> SELECTs will follow the chain each time we do an index lookup.
> But a sequential scan still follows the chain, and that isn't going to
> prune. Why are we more worried about index chain lookups than
> sequential scan lookups?
No, a seqscan *doesn't* follow HOT chains. It just looks at every live
line pointer on the page, sequentially. An indexscan will have to
follow HOT chains, or it will miss tuples it needs to return.
>> The SeqScan doesn't follow the chains, so can't easily determine whether
>> there are any long chains that need pruning. Its only when we come in
>> via an index that we need to walk the chain to the latest tuple version
>> and in that case we learn how long the chain is.
> Uh, as I understand it, every access follows the ctid, so why doesn't a
> sequential scan follow the chain?
Up to now, normal searches (whether seq or index) have never paid the
slightest attention to t_ctid. That's only used when a READ COMMITTED
update realizes it's trying to update a non-latest version of a row.
regards, tom lane