Aleksander Alekseev <a.aleks...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers