In article <9sphq7$k0h$1@news.tht.net>, "Jeff Boes" <jboes@nexcerpt.com>
wrote:
> and 2) very long COMMIT times for some long transactions: I'm talking
> about upwards of 10-20 MINUTES to commit after doing hundreds of
> inserts, updates and deletes in one transaction. The table involved has
> some 20K rows, and is read and updated a few rows at a time by many
> processes, but only one (the one doing large numbers of rows) has the
> lengthy COMMIT times.
>
> Did this come about because of the increase in WAL count?
Oops. This turns out not to be a COMMIT time, but instead it's happening
in a NOTIFY operation just after the COMMIT. What would cause a
previously-quick NOTIFY step to become many minutes long?
--
Jeff Boes vox 616.226.9550
Database Engineer fax 616.349.9076
Nexcerpt, Inc. jboes@nexcerpt.com
