Re: Shared invalidation cache messages for temporary tables

On Mar 14, 2011, at 9:29 AM, Robert Haas wrote:

> On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> Since your original email is fairly unclear about what you think the
>>> problem is, it's a bit hard to speculate here, but like Simon, I don't
>>> see any obvious problem here. Maybe you're asking not so much about
>>> inserts, updates, or deletes into temporary tables but about creating
>>> and making modifications to them, which will generate catcache and
>>> relcache flushes when the pg_class/pg_attribute entries are updated.
>>> But I don't think those invalidation messages can be optimized away,
>>> since other backends can access temporary tables of other sessions in
>>> limited ways - for example, they can drop them.
>>
>> Sorry, yes that was my point --- should we be doing as much cache
>> invalidation traffic for temporary tables as we are doing? I think you
>> are saying we are fine and there are no optimizations possible.
>
> Yeah, I think so. I mean, if you have a concrete example of this
> causing a problem, then we can look into it, but my intuition is that
> it's OK. Programmers intuition are notoriously wrong, of course, so
> we're all just shooting in the dark until we have something to
> measure.

Sounds like there should be a comment somewhere in the code that explains why we actually need those messages...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net