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
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 th
On 4/5/19 5:45 PM, 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 ro
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 ever
