From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Kim <kim@myemma.com>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unusual performance for vac following 8.2upgrade
Date: Thu, 11 Jan 2007 21:51:39 -0500
Message-ID: <29730.1168570299@sss.pgh.pa.us> (raw)
In-Reply-To: <20070112010918.GM10464@alvh.no-ip.org>
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>
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 :-(
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@commandprompt.com, simon@2ndquadrant.com, kim@myemma.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unusual performance for vac following 8.2upgrade
In-Reply-To: <29730.1168570299@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox