From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: User concurrency thresholding: where do I look?
Date: Thu, 19 Jul 2007 13:45:15 -0400
Message-ID: <14009.1184867115@sss.pgh.pa.us> (raw)
In-Reply-To: <20070719173704.GA12084@alvh.no-ip.org>
References: <200707190828.59088.josh@agliodbs.com>
<20070719154912.GG6538@alvh.no-ip.org>
<200707190922.24497.josh@agliodbs.com>
<12686.1184865938@sss.pgh.pa.us>
<20070719173704.GA12084@alvh.no-ip.org>
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> AFAIK you'd get hard failures, not slowdowns, if you ran out of lock
>> space entirely;
> Well, if there still is shared memory available, the lock hash can
> continue to grow, but it would slow down according to this comment in
> ShmemInitHash:
Right, but there's not an enormous amount of headroom in shared memory
beyond the intended size of the hash tables. I'd think that you'd start
seeing hard failures not very far beyond the point at which performance
impacts became visible. Of course this is all speculation; I quite
agree with varying the table-size parameters to see if it makes a
difference.
Josh, what sort of workload is being tested here --- read-mostly,
write-mostly, a mixture?
> However I was talking to Josh Drake yesterday and he told me that
> pg_dump was spending some significant amount of time in LOCK TABLE when
> there are lots of tables (say 300k).
I wouldn't be too surprised if there's some O(N^2) effects when a single
transaction holds that many locks, because of the linked-list proclock
data structures. This would not be relevant to Josh's case 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-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@commandprompt.com, josh@agliodbs.com
Subject: Re: User concurrency thresholding: where do I look?
In-Reply-To: <14009.1184867115@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