To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org
Subject: Re: User concurrency thresholding: where do I look? 
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>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Thu, 19 Jul 2007 13:37:04 -0400"
Date: Thu, 19 Jul 2007 13:45:15 -0400
Message-ID: <14009.1184867115@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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