On Thu, Jan 11, 2007 at 09:51:39PM -0500, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Can we actually get rid of pg_class entries for temp tables. Maybe > > creating a "temp pg_class" which would be local to each session? Heck, > > it doesn't even have to be an actual table -- it just needs to be > > somewhere from where we can load entries into the relcache. > > A few things to think about: > > 1. You'll break a whole lotta client-side code if temp tables disappear > from pg_class. This is probably solvable --- one thought is to give > pg_class an inheritance child that is a view on a SRF that reads out the > stored-in-memory rows for temp pg_class entries. Likewise for > pg_attribute and everything else related to a table definition. > > 2. How do you keep the OIDs for temp tables (and their associated > rowtypes) from conflicting with OIDs for real tables? Given the way > that OID generation works, there wouldn't be any real problem unless a > temp table survived for as long as it takes the OID counter to wrap all > the way around --- but in a database that has WITH OIDS user tables, > that might not be impossibly long ... > > 3. What about dependencies on user-defined types, functions, etc? > How will you get things to behave sanely if one backend tries to drop a > type that some other backend is using in a column of a temp table? Even > if you put entries into pg_depend, which would kind of defeat the point > of not having on-disk catalog entries for temp tables, I don't see how > the other backend figures out what the referencing object is. > > I don't really see any solution to that last point :-(
Perhaps it would be better to partition pg_class and _attributes based on whether an object is temporary or not. Granted, that still means vacuuming is a consideration, but at least it wouldn't be affecting pg_class itself. Separating temp objects out would also make it more reasonable to have the system automatically vacuum those tables after every X number of dropped objects. Unfortunately, that still wouldn't help with the OID issue. :( Unless there was a SERIAL column in pg_class_temp and other parts of the system could differentiate between temp and non-temp objects. -- Jim Nasby [EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
