Received: from localhost (maia-4.hub.org [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id A94FD9FB294
	for <pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  3 Jul 2007 07:00:35 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 64998-08 for
	<pgsql-hackers-postgresql.org@postgresql.org>;
	Tue,  3 Jul 2007 07:00:11 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from oxford.xeocode.com (unknown [87.127.95.194])
	by postgresql.org (Postfix) with ESMTP id E4DC49FB421
	for <pgsql-hackers@postgresql.org>;
	Tue,  3 Jul 2007 07:00:08 -0300 (ADT)
Received: from localhost.enta.net ([127.0.0.1] helo=oxford.xeocode.com)
	by oxford.xeocode.com with esmtp (Exim 4.67)
	(envelope-from <stark@enterprisedb.com>)
	id 1I5fAs-0001aF-BA; Tue, 03 Jul 2007 10:59:58 +0100
From: Gregory Stark <stark@enterprisedb.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Alvaro Herrera" <alvherre@commandprompt.com>,
	"Jim Nasby" <decibel@decibel.org>,
	"Pavel Stehule" <pavel.stehule@gmail.com>,
	"PostgreSQL-development" <pgsql-hackers@postgresql.org>
Subject: Re: what is difference between LOCAL and GLOBAL TEMP TABLES in
	PostgreSQL
In-Reply-To: <27473.1183431616@sss.pgh.pa.us> (Tom Lane's message of "Mon, 02
	Jul 2007 23:00:16 -0400")
Organization: EnterpriseDB
References: <162867790707011431u71e53543x19e64e5bb160b124@mail.gmail.com>
	<17505.1183326406@sss.pgh.pa.us>
	<19689F96-2FE1-4343-BE86-94317AEB0C57@decibel.org>
	<19728.1183394601@sss.pgh.pa.us>
	<20070703004634.GB4757@alvh.no-ip.org>
	<27473.1183431616@sss.pgh.pa.us>
X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX.hackers" 11044)
Date: Tue, 03 Jul 2007 10:59:57 +0100
Message-ID: <873b056c4i.fsf@oxford.xeocode.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200707/62
X-Sequence-Number: 104977


"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Tom Lane escribi=F3:
>>> I rather doubt that.  The most likely implementation would involve
>>> cloning a "template" entry into pg_class.
>
>> How about a new relkind which causes the table to be located in
>> PGDATA/base/<dboid>/pg_temp_<backendid>/<relfilenode>
>> So each backend can have its own copy of the table with the same
>> relfilenode; there's no need for extra catalog entries.
>
> Uh-huh.  And what do you do with relpages, reltuples, relfrozenxid, and
> pg_statistic entries?  What if one backend wants to TRUNCATE or CLUSTER
> its copy (requiring a new relfilenode)?  Where does ALTER TABLE fit into
> this?

I would have suggested that when we construct the relcache entry for the ta=
ble
we substitute a local version of refilenode for the global one.=20

None of those sound like hard problems. Certainly it's more invasive this w=
ay
but the other way is just a hack for complying with the letter of the spec
without actually making it work right. It would be silly and in many use
cases useless to have regular DML operating on data which has no business
being anything but backend-local generate garbage in on-disk catalog tables.

I had a strange thought though. The ideal data structure for local
pg_statistic data in the unlikely case that users analyze their local tables
would in fact be a global temporary table as well. I wonder if we could
bootstrap something similar for pg_class as well.

Incidentally, for what would imagine relfozenxid would be useful for these
tables anyways?

--=20
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com