On Fri, Jun 17, 2011 at 8:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 3:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Not so. The extra locking would only occur on the first lock
>> acquisition after DDL operations occur. If that was common then your
>> other performance patch would not be an effective optimisation. There
>> is no additional locking from what I've proposed in the common code
>> path - that's why we have a relcache.
>
> The extra locking would also occur when *initially* building relcache
> entries. In other words, this would increase - likely quite
> significantly - the overhead of backend startup. It's not going to be
> sufficient to do this just for pg_class; I think you'll have to do it
> for pg_attribute, pg_attrdef, pg_constraint, pg_index, pg_trigger,
> pg_rewrite, and maybe a few others I'm not thinking of right now.
Nothing you say here is accurate, regrettably.
The "extra locking" would be one call to the lock manager per
relation. Taken in shared mode, so it doesn't block.
I see no reason at all to have separate locks for each catalog table,
since it's the relation lock that is the top level lock.
Locking is a very well known solution to such problems. We use it
everywhere and we can use it here, and now.
I think you'd better wait to see the patch.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services