Re: Implementation of global temporary tables?

On 2015-02-02 12:24:44 +0100, Pavel Stehule wrote:
> 2015-02-02 12:04 GMT+01:00 Andres Freund <andres(at)2ndquadrant(dot)com>:
> > > 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.

The amount of complexity that'd be involved to store catalog data in a
separate relation around the caches and accesses would be significant. I
don't think that's a realistic option.

> > > 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

What does it have to do with temp tables then?

> > 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

I'm honestly not particularly concerned about that problem. For one, we
don't auto-analyze/vacuum temp tables. For another, it'd be
comparatively easy to gather reltuples/relpages/stats from session local
state if necessary. Those are all only accessed from a few places.

Greetings,

Andres Freund

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