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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
