Re: including backend ID in relpath of temp rels - updated patch

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Sure, it tops out somewhere, but 32K is way too close to configurations
>> we know work well enough in the field (I've seen multiple reports of
>> people using a couple thousand backends).

> Well, I wouldn't expect anyone to use an exclusive lock for readers
> without a good reason, but you still have n backends that each have to
> read, presumably, about O(n) messages, so eventually that's going to
> start to pinch.

Sure, but I don't see much to be gained from multiple queues either.
There are few (order of zero, in fact) cases where sinval messages
are transmitted that aren't of potential interest to all backends.
Maybe you could do something useful with a very large number of
dynamically-defined queues (like one per relation) ... but managing that
would probably swamp any savings.

> Do you think it's worth worrying about the reduction in the number of
> possible SI message types?

IIRC the number of message types is the number of catalog caches plus
half a dozen or so. We're a long way from exhausting even a 1-byte
ID field; and we could play more games if we had to, since there would
be a padding byte free in the message types that refer to a catalog
cache. IOW, 1-byte id doesn't bother me.

regards, tom lane