The explain plan tree only shows the time to fetch/compute the new rows,
not to actually perform the update, update indexes, or fire triggers.
If there is a big discrepancy then the extra time must be going into
one of those steps.
8.1 does show trigger execution time separately, so the most obvious
problem (unindexed foreign key reference) seems to be excluded, unless
the OP just snipped that part of the output ...
Yeah, that quite frequent problem with updates. Try to separate create a
copy of the table, i.e.
CREATE TABLE test_table AS SELECT * FROM table;
and try to execute the query on it.
What tables do reference the original table using a foreign key? Do they
have indexes on the foreign key column? How large are there referencing
tables? Are these tables updated heavily and vacuumed properly (i.e.
aren't they bloated with dead rows)?
I'm not sure if the FK constraints are checked always, or just in case
the referenced column is updated. I guess the FK check is performed only
in case of DELETE or when the value in the FK column is modified (but
update of the primary key is not very frequent I guess).
Are there any triggers and / or rules on the table?
regards
Tomas
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
