Robert Haas wrote: > 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.
Check. This is the most serious issue, IMV. > 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. Check. We could think about relaxing this restriction, which would enable the feature to satisfy that use case. (I think the main complication there is the init fork of btrees on those catalogs; other relations could just be truncated to empty on restart.) > 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. You also save catalog bloat ... These benefits may not be tremendous, but I think they may be good enough for many users. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
