DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=mAF8dH57Umq86D5kDlF4AdvqQWSHtucaPusBOWznEbfyQPVg4O6ZC+eu07Zy8gm2j/
	nYNbmrENgeH8P6Dr+DL9wGym6a40TqHfOHkU6uMNWVdVAb+rbpw4xemMPkvt+wwHmLjb
	1VZd0zlnVF+Mfn4xZTQK/JnXb2W6yBWJjM8Kc=
MIME-Version: 1.0
In-Reply-To: <u2o603c8f071004231952i36642ae6u9d6a7eae6eb6ff32@mail.gmail.com>
References: <u2o603c8f071004231952i36642ae6u9d6a7eae6eb6ff32@mail.gmail.com>
Date: Sat, 24 Apr 2010 08:42:42 +0200
Message-ID: <w2i162867791004232342p183892bbw87eccb7267079f03@mail.gmail.com>
Subject: Re: global temporary tables
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2010/4/24 Robert Haas <robertmhaas@gmail.com>:
> A couple of recent threads made got me thinking again about the idea
> of global temporary tables. =C2=A0There seem to be two principal issues:
>
> 1. What is a global temporary table?
>
> 2. How could we implement that?
>
> Despite rereading the "idea: global temp tables" thread from April
> 2009 in some detail, I was not able to get a clear understanding of
> (1). =C2=A0What I *think* it is supposed to mean is that the table is a
> permanent object which is "globally" visible - that is, it's part of
> some non-temp schema like public or $user and it's column definitions
> etc. are visible to all backends - and it's not automatically removed
> on commit, backend exit, etc. - but the *contents* of the table are
> temporary and backend-local, so that each new backend initially sees
> it as empty and can then insert, update, and delete data independently
> of what any other backend does.
>
> As to (2), my thought is that perhaps we could implement this by
> instantiating a separate relfilenode for the relation for each backend
> which accesses it. =C2=A0relfilenode would be 0 in pg_class, as it is for
> "mapped" relations, but every time a backend touched the rel, we'd
> allocate a relfilenode and associated the oid of the temp table to it
> using some kind of backend-local storage - actually similar to what
> the relmapper code does, except without the complexity of ever
> actually having to persist the value; and perhaps using a hash table
> rather than an array, since the number of mapped rels that a backend
> can need to deal with is rather more limited than the number of temp
> tables it might want to use.

it is good idea.

I missing some ideas about statistics, about indexes.

Regards
Pavel Stehule
>
> Thoughts?
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>