>This surprises you why?
I don't know anything about how PG stores keys along with their
references to the actual rows but my assumption was that that reference
is some sort of an index into a table that maps the reference to an
actual disk/file address. So even if the row or the page with the row on
it is physically moved to a different location in the disk file, the
unrelated indexes would not have to be changed because only the
disk/file address changes but the reference does not. If PG does not
work in a similar fashion then I understand the locks.
When you update a table postgres makes a copy of the row being updated
so it has to create new index entries pointing to the new version of
the row... but it keeps old index entries pointing to the prior
version of the row because if there are concurrent queries to those
tables that looks for that particular row and you haven't committed
yet we still want the old version (old index entry)...
--
regards,
Jaime Casanova
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook
