Thread: Temp tables, pg_class_temp and AccessExclusiveLocks
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
On 31 October 2014 14:53, Simon Riggs <simon@2ndquadrant.com> wrote: > While investigating how to reduce logging of AccessExclusiveLocks for > temp tables, I came up with the attached patch. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
Hi
good idea. Mix of these both strategies can be a base for global temp tables implementation.2014-10-31 15:53 GMT+01:00 Simon Riggs <simon@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