Thank you everyone for great comments! > have a permanent pg_class which holds the records for permanent tables > and an *unlogged* table, say pg_class_unlogged, which holds records > for temporary tables. Now everybody can see everybody else's data, > yet we don't have to create permanent catalog entries. So we are not > dead. All of the temporary catalog tables vanish on a crash, too, and > in a very clean way, which is great. > > [...] > > Overall I feel like the development effort that it would take to make > this work would almost certainly be better-expended elsewhere.
Agree. This is an interesting idea but considering named drawbacks, especially: > 2. You can't write to unlogged tables on standby servers, so this > doesn't help solve the problem of wanting to use temporary tables on > standbys. ... I don't think it's worth an effort. >> when you use global temporary tables, then you create it only once - >> like usual tables. >> >> you don't drop these tables. > > I share the view that this is a better/simpler solution to the problem. > It will still require virtual (in-memory) tuples for pg_statistic > records, but everything else works pretty much as for regular tables. In > particular there are no problems with dependencies. > > The obvious disadvantage is that it requires changes to applications. Frankly I have much more faith in Tom's idea of using virtual part of the catalog for all temporary tables, i.e turning all temporary tables into "fast" temporary tables. Instead of introducing a new type of temporary tables that solve catalog bloating problem and forcing users to rewrite applications why not just not to create a problem in a first place? > I think one way to fix that would be to store the virtual tuples in > shared memory (instead of process memory). That will certainly require > locking and synchronization, but well - it needs to be shared. I believe currently this is the most promising course of action. In first implementation we could just place all virtual part of the catalog in a shared memory and protect it with a single lock. If it will work as expected the next step would be elimination of bottlenecks --- using multiple locks, moving part of a virtual catalog to local backend's memory, etc. As always, please don't hesitate to share any thoughts on this topic! -- Best regards, Aleksander Alekseev -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers