"Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> Isn't the extra machination for C.I.C. just useless complication?
>>> What's the point of avoiding creation of new broken HOT chains when
>>> you still have to deal with existing ones?
>
>> IMHO the extra step in C.I.C simplifies the index build.
>
> If you make the change suggested above, I think you don't need to do
> things differently in C.I.C.
It seems to me if you wait out transactions as you come across them you could
end up waiting a whole lot longer than the way it works now where it waits
them all out at the end of the first pass.
>> OK. So if I get you correctly, you are suggesting to acquire cleanup lock.
>> If we don't get that, we don't to any maintenance work. Otherwise, we prune
>> and repair fragmentation in one go.
>
> Yeah, that's what I'm thinking; then there's no need to track a separate
> page state where we've pruned but not defragmented.
Note that you still need to do it in two steps, you just get to postpone the
pruning work to the same point in time as the defragmenting. You can never
"acquire" the cleanup lock when it comes time to insert a new update version
since the executor still holds references to the original tuple.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
