Re: Implementation of global temporary tables?

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Implementation of global temporary tables?
Date: 2015-02-02 12:36:35
Message-ID: CAOeZVie_N5vVO=nT-JoZm62Pbfs+LOh2BHfMYHq-7vtosipJdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Not to mention the problems we might end up in. We still have corner cases
in our cache code, and a new heap on top of it all might be just too
painful.

>
> > > > 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 what Pavel means here is that we do not need a full fledged heap
layer and rather only a minimal API from a per session memory context.
However, that might be still as painful because we will eventually end up
inventing mechanisms for syscache and typcache to work with this storage,
which IMO is the biggest pain point around this idea.

Regards,

Atri

Regards,

Atri
*l'apprenant*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-02 12:57:18 Re: Release note bloat is getting out of hand
Previous Message Michael Paquier 2015-02-02 12:21:39 Re: Proposal : REINDEX xxx VERBOSE