Re: Implementation of global temporary tables? - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Implementation of global temporary tables?
Date
Msg-id CAFj8pRCdiVhyoicJgOJEukFwTTF5xyjv6QQMx+dRgLRc9CrBXw@mail.gmail.com
Whole thread Raw
In response to Re: Implementation of global temporary tables?  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Implementation of global temporary tables?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers


2015-02-02 12:04 GMT+01:00 Andres Freund <andres@2ndquadrant.com>:
Hi,

On 2015-02-02 11:15:22 +0100, Pavel Stehule wrote:
> Six years ago we did discuss about global temporary tables - persistent
> schema, ephemeral data.
>
> http://postgresql.nabble.com/idea-global-temp-tables-td2007217.html
>
> I am thinking so some reasons why implement this feature are valid:
>
> * we can get some performance benefit against current temp tables - less
> the catalogue bloating,
>
> * we can simplify a static validation of plpgsql functions when temp tables
> are used,
>   more global temp tables are little bit comfortable for developers,
>
> * we can simplify migration from some other databases, where global temp
> tables are default.

I agree that the feature would be interesting.

> 2. Implementation
>
> I see three possible ways how to implement it:
>
> 2.a - using on demand created temp tables - most simple solution, but
> doesn't help with catalogue bloating

Yea, that's no good.

> 2.b - using unlogged tables for holding statistics, relfilenode, and all
> necessary data

I can't follow why that'd achieve anything?

1. Main catalogue will be stable.
2. There is not necessary to implement new storage and it can helps with transaction support.
 

> 3.c - store ephemeral metadata only in memory without MVCC

I think that's not an option. That'd end up being a massive amount of
duplication at a low rate of functionality.

I don't plan to implement a storage - I expect only few functions for store/read data from session memory context


I think it's more realistic way to implement is to have a separate
'relpersistence' setting for global temp tables. The first access to
such one in a session (or xact if truncate on commit) copies the table
from the _init fork. By having the backend id in all filenames (besides
the init fork) they're unique between sessions.


If I understand well, it is similar to my fast implementation from 2008. It works partially,  because it doesn't solve other (session) property - like relpages, reltuples and related data from pg_statistics
 
Or something roughly like that.

Greetings,

Andres Freund

--
 Andres Freund                     http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Implementation of global temporary tables?
Next
From: Sawada Masahiko
Date:
Subject: Proposal : REINDEX xxx VERBOSE