Date: Fri, 12 Jan 2007 11:33:06 -0600
From: "Jim C. Nasby" <jim@nasby.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>,
	Simon Riggs <simon@2ndquadrant.com>, Kim <kim@myemma.com>,
	pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] unusual performance for vac following 8.2upgrade
Message-ID: <20070112173306.GA70584@nasby.net>
References: <45A671CD.1050706@myemma.com> <27939.1168539652@sss.pgh.pa.us>
	<45A68C74.4080405@myemma.com> <28949.1168544710@sss.pgh.pa.us>
	<1168548006.3951.564.camel@silverbirch.site>
	<5414.1168549900@sss.pgh.pa.us>
	<1168557275.3990.49.camel@silverbirch.site>
	<20070112010918.GM10464@alvh.no-ip.org>
	<29730.1168570299@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <29730.1168570299@sss.pgh.pa.us>
User-Agent: Mutt/1.5.13 (2006-08-11)

On Thu, Jan 11, 2007 at 09:51:39PM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> 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                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)