On Tue, Aug 16, 2016 at 8:03 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 8/16/16 11:59 AM, Robert Haas wrote: > ... >> >> That doesn't really solve the problem, because OTHER backends won't be >> able to see them. So, if I create a fast temporary table in one >> session that depends on a permanent object, some other session can >> drop the permanent object. If there were REAL catalog entries, that >> wouldn't work, because the other session would see the dependency. > > Some discussion about TEMP functions is happening on -general right now, and > there's other things where temp objects are good to have, so it'd be nice to > have a more generic fix for this stuff. Is the idea of "partitioning" the > catalogs to store temp objects separate from permanent fatally flawed?
I wouldn't say it's fatally flawed. But you might need a world-renowned team of physicians working round the clock for days in a class 1 trauma center to save it. If you imagine that you have a permanent pg_class which holds permanent tables and a temporary pg_class per-backend which stores temporary tables, then you very quickly end up with the same deadly flaw as in Aleksander's design: other backends cannot see all of the dependency entries and can drop things that they shouldn't be permitted to drop. However, you could 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. However: 1. The number of tables for which we would need to add a duplicate, unlogged table is formidable. You need pg_attribute, pg_attrdef, pg_constraint, pg_description, pg_type, pg_trigger, pg_rewrite, etc. And the backend changes needed so that we used the unlogged copy for temp tables and the permanent copy for regular tables is probably really large. 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. 3. While it makes creating temporary tables a lighter-weight operation, because you no longer need to write WAL for the catalog entries, there's probably still substantially more overhead than just stuffing them in backend-local RAM. So the performance benefits are probably fairly modest. Overall I feel like the development effort that it would take to make this work would almost certainly be better-expended elsewhere. But of course I'm not in charge of how people who work for other companies spend their time... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers