From: Tom Lane <tgl@sss.pgh.pa.us>
To: alex-lists-pgsql@yuriev.com
Cc: pgsql-sql@postgresql.org
Subject: Re: INSERT waiting under heavy load
Date: Fri, 06 Jan 2006 16:49:09 -0500
Message-ID: <23072.1136584149@sss.pgh.pa.us> (raw)
In-Reply-To: <20060106201657.GB1890@s2.yuriev.com>
References: <20060106184227.GA1890@s2.yuriev.com>
<22727.1136580728@sss.pgh.pa.us>
<20060106201657.GB1890@s2.yuriev.com>
alex-lists-pgsql@yuriev.com writes:
> if the problem is caused by the the acquire lock->modify column->release
> lock on the table 1, then why does it increase significantly increase as the
> number of entries in the table 3 grows? The simulation maintains pretty much
> constant rate of new requests coming to table 3.
Are you vacuuming table 1 on a regular basis while you do this?
Accumulation of dead tuple versions in table 1 is a pretty severe
performance risk in the sort of scenario you are describing.
(I'm not sure why it would manifest as transactions showing "INSERT
waiting" state though.)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: tgl@sss.pgh.pa.us, alex-lists-pgsql@yuriev.com
Subject: Re: INSERT waiting under heavy load
In-Reply-To: <23072.1136584149@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox