Tom Lane wrote:
Bruno Wolff III <[EMAIL PROTECTED]> 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...)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
