Hi good idea. Mix of these both strategies can be a base for global temp tables implementation.
Pavel 2014-10-31 15:53 GMT+01:00 Simon Riggs <si...@2ndquadrant.com>: > While investigating how to reduce logging of AccessExclusiveLocks for > temp tables, I came up with the attached patch. > > My feeling was "that's an ugly patch", but it set me thinking that a > more specialised code path around temp tables could be useful in other > ways, and therefore worth pursuing further. > > The patch creates a relation_open_temp(), which could then allow a > RelationIdGetTempRelation() which could have a path that calls > ScanPgRelation on a new catalog table called pg_class_temp, and other > _temp catalog table accesses. > > So we could isolate all temp table access to specific tables. That would > * cause less bloat in the main catalog tables > * avoid logging AccessExclusiveLocks on temp tables > * less WAL traffic > > Why less WAL traffic? Because we can choose then to make *_temp catalog > tables > 1. use unlogged table mechanism > 2. use local tables inside the local buffer manager > > My preference would be (1) because all we need to do is change the > catalog table oid when searching, we don't need to do anything else. > > -- > Simon Riggs http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, 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 >
