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
