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 <br...@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 <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
