Tom Lane wrote:
>Bruno Wolff III <bruno@wolff.to> writes:
>
>
>>It probably has one visible row in it. If it can changed a lot, there
>>may be lots of deleted tuples in a row. That would explain why an
>>index scan speeds things up.
>>
>>
>
>Right, every UPDATE on unique_ids generates a dead row, and a seqscan
>has no alternative but to wade through them all. When a unique index is
>
Speaking of which, since the row is locked with select for update (so it
can't be involved in any other transactions anyway) and the change
doesn't change the length of the row, can't it just be updated in-place,
or would that break something else? (pardon if this is answered already,
me thinks its time to go reread the todo's and the architecture
documents...)
