Re: namespace dilemma

jeff(dot)greco(at)bluehavenmg(dot)com writes:
> [ there isn't any locking associated with namespaces ]

Nor any other kind of object except tables...

There have been some discussions about fixing this, but the idea has
bogged down in concerns about performance and possible deadlocks.

To be completely correct, a query as simple as
select * from foo where col1 = 42;
would have to obtain locks on not only table foo, but
- foo's namespace
- the integer '=' operator
- the int4eq() function underlying the operator
- the namespace(s) of the operator and function
- any other namespaces preceding these in your search path
(else someone might insert a new foo or '=' that should
take precedence in your query)
- maybe also some locks on data types
so you can see that we'd probably be talking at least one order of
magnitude increase in the traffic through the lock manager, which is
already something of a bottleneck :-(. Plus this traffic would be
very heavily concentrated on a few popular objects, such as the
pg_catalog schema. The lock manager is not really designed to have
large numbers of processes taking out locks on a single object, and
would probably need considerable work to make the performance
acceptable.

The concern about extra deadlocks is more hypothetical, but I think
there would definitely be some risk there, with so many more lock
requests flying around the system.

All in all it looks like a lot of work to solve a problem that doesn't
affect very many people. I can't recall many complaints other than
yours ...

regards, tom lane