In article <9sphq7$k0h$[EMAIL PROTECTED]>, "Jeff Boes" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
