Re: Implementation of global temporary tables?

2015-02-02 13:15 GMT+01:00 Andres Freund <andres(at)2ndquadrant(dot)com>:

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

it is mechanism how to store a session metadata related to global temp
tables

>
> > > 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.
>
>
so I don't see a big differences from 3.c - all session metadata will
stored in session memory.

I didn't write code, so I have not a knowledge about details.

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