"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Any chance that some of these improvements could be applied to temp > tables created with the PostgreSQL-specific syntax while we're at it?
You mean the Postgres-specific behavior, no? Trying to support a table without *any* pre-existing catalog entries seems even harder than doing it without changing the pre-existing catalog entries. It's something we've thought about before and failed to find a decent solution for. I think there was some discussion of allowing pg_class and other relevant tables to implicitly have session-local child tables that would hold session-local catalog entries (and be stored in the local bufmgr); but AFAIR we never worked all the bugs out of the concept. > The need for several tables to be created on disk to materialize a > single temp table currently causes performance problems in some > contexts. I don't think the updates to the system tables have the > same magnitude of performance hit as creating these tables, especially > if write barriers are on. True; it's pure supposition that avoiding the catalog thrashing is actually important in context of everything else that has to happen. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers