Aleksander Alekseev <a.alekseev@postgrespro.ru> writes:
> There are applications that create and delete a lot of temporary
> tables. Currently PostgreSQL doesn't handle such a use case well.
True.
> Fast temporary tables work almost as usual temporary tables but they
> are not present in the catalog. Information about tables is stored in
> shared memory instead. This way we solve a bloating problem.
I think you have no concept how invasive that would be. Tables not
represented in the catalogs would be a disaster, because *every single
part of the backend* would have to be modified to deal with them as
a distinct code path --- parser, planner, executor, loads and loads
of utility commands, etc. I do not think we'd accept that. Worse yet,
you'd also break client-side code that expects to see temp tables in
the catalogs (consider psql \d, for example).
I think a workable solution to this will still involve catalog entries,
though maybe they could be "virtual" somehow.
> We should use *shared* memory so autovacuum could find these tables.
Autovacuum does not touch temp tables; never has and never will, at
least not with the current flavor of temp tables that don't keep their
data in shared buffers. Also, if you insist on keeping the data in
shared memory, there will be a fixed limit on how many temp tables
can exist at one time.
regards, tom lane
