resolved. sorry for not posting the resolution earlier.
it was a good puzzler. turns out the postgresql server used
network-attached disks. and the updated table had no index for the
updated columns. so, the update required a serial scan of the table over
the network. thus, the high cpu usage for updating a single row.
kevin
On 4/7/2019 11:41 PM, Laurenz Albe wrote:
Kevin Wilkinson wrote:
on 10.2, we're seeing very high cpu usage when doing an update statement
on a relatively small table (1GB). one of the updated columns is text,
about 1k bytes. there are four threads doing similar updates
concurrently to the same table (but different rows). each thread does an
update about every two seconds, i.e., the tables gets updated every 1/2
second. the stack trace below shows the process stuck in reading the
update results. this seems very odd. has anyone seen something similar?
this is a modest server of 8 cores, all of which are 90% busy.
Try to profile the server ("perf" on Linux) to see where the time is spent.
Are there any foreign key constraints pointing to the table being updated?
Then make sure that either no key column is updates or that the foreign
keys are indexed.
Yours,
Laurenz Albe
