update on global temporary and unlogged tables - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | update on global temporary and unlogged tables |
Date | |
Msg-id | AANLkTim=5af41BKFvZ=ofVJ465kxQkJdjHQZUDz3k1d9@mail.gmail.com Whole thread Raw |
Responses |
Re: update on global temporary and unlogged tables
Re: update on global temporary and unlogged tables |
List | pgsql-hackers |
I haven't had a chance to do a great deal of work on this project, but I'm hoping to get back to it at some point and, in the meantime, thought that it might be useful to circulate a few thoughts I've had so far. 1. As common architecture for both features, I think that it might make sense to replace the existing relistemp (bool) field with a relpersistence (char) field. The current tests against rel->rd_istemp can be replaced with macros testing the exact property we really care about in that situation. I'm thinking of RelationNeedsWAL(), RelationUsesLocalBuffers(), and RelationUsesTempNamespace(). 2. With respect to global temporary tables, I've hit a fairly serious roadblock in the form of relfrozenxid. For a permanent table, VACUUM by any backend can advance relfrozenxid; for a backend-local temporary table, VACUUM by the owning backend can advance relfrozenxid. But for a global temporary table, the proper value for relfrozenxid is the earliest value for any backend that has stored tuples into the table. I'm not immediately sure what to do about this. Tom's previous suggestion of cloning the catalog entries for each backend that tries to access the table is one possible alternative, but I don't like that much for reasons previously discussed. Incidentally, per some previous discussion, I took a look at what Oracle does with respect to DDL on global temp tables, and I gather that they allow it if no session has "bound" (instantiated?) the table. Maybe some infrastructure along those lines would be useful in dealing with the VACUUM problem also; not sure. 3. With respect to unlogged tables, the major obstacle seems to be figuring out a way for these to get automatically truncated at startup time. As with temporary table cleanup in general, the problem here is that you can't do the obvious thing of iterating through pg_class and truncating each unlogged table you find without greatly complicating the startup sequence. However, I think there's a fairly easy way around this problem: truncating a table basically means removing all segments and relation forks other than the first segment of the main fork, and truncating that one to zero length. So we could do it the same way we clean up temporary files - namely, based on the file name - if we made the filenames for unlogged tables distinguishable from those for regular and temporary tables. What I'm thinking about is reserving a backend ID of -2 for this purpose via some suitable constant definition, just as -1 (InvalidBackendId) represents a permanent table in this context. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
pgsql-hackers by date: