Message-ID: <45A74FA0.8090801@archonet.com>
Date: Fri, 12 Jan 2007 09:06:40 +0000
From: Richard Huxton <dev@archonet.com>
User-Agent: IceDove 1.5.0.9 (X11/20061220)
MIME-Version: 1.0
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: [HACKERS] unusual performance for vac following 8.2upgrade
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>
In-Reply-To: <29730.1168570299@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

> 2. How do you keep the OIDs for temp tables (and their associated
> rowtypes) from conflicting with OIDs for real tables?

> 3. What about dependencies on user-defined types, functions, etc?

Is there not some gain from just a "standard" partitioning of pg_class 
into: (system-objects, user-objects, temp-objects)? I'd expect them to 
form a hierarchy of change+vacuum rates (if you see what I mean).

-- 
   Richard Huxton
   Archonet Ltd