Re: Shared invalidation cache messages for temporary tables

Jim Nasby wrote:
> On Mar 14, 2011, at 9:29 AM, Robert Haas wrote:
> 
> > On Mon, Mar 14, 2011 at 10:21 AM, Bruce Momjian <bruce@momjian.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...

Done.

-- Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +