"Kevin Grittner" <Kevin.Grittner@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
