Robert Haas wrote: > On Mon, Mar 14, 2011 at 8:42 AM, Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
