Robert Haas wrote:
> On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian <bruce@momjian.us> wrote:
> > Simon Riggs wrote:
> >> On Fri, 2011-03-11 at 20:44 -0500, Bruce Momjian wrote:
> >> > Looking at the code, it seems we create shared invalidation messages for
> >> > temporary table activity? ?Is this true? ?Should we be avoiding it?
> >> >
> >> > I tested this by reviewing the code and checking calls to
> >> > CacheInvalidateHeapTuple(), which happens for temporary table
> >> > creation/destruction.
> >>
> >> Yes, that gets called.
> >>
> >> But in PrepareForTupleInvalidation() we ignore everything apart from
> >> system relations, as the first check.
> >
> > OK, so this is no problem? ?There is no optimization needed here?
> > Thanks.
>
> 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.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
