Re: [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

2016-08-15 11:01 GMT+02:00 Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>:

> > > >>> I think the whole idea of a fast temporary table is that there
> > > >>> are no catalog entries. If there are no catalog entries, then
> > > >>> dependencies are not visible. If there ARE catalog entries, to
> > > >>> what do they refer? Without a pg_class entry for the table,
> > > >>> there's no table OID upon which to depend.
> > >
> > > >> TBH, I think that the chances of such a design getting committed
> > > >> are not distinguishable from zero. Tables have to have OIDs;
> > > >> there is just too much code that assumes that. And I seriously
> > > >> doubt that it will work (for any large value of "work") without
> > > >> catalog entries.
> > >
> > > > That seems a bit too defeatist.
> > >
> > > Huh? I didn't say we shouldn't work on the problem --- I just
> > > think that this particular approach isn't good. Which you seemed
> > > to agree with.
> >
> > I took your statement to mean that they need a pg_class entry - even
> > if there were a partial solution to the pg_depend problem allowing to
> > avoid pg_attribute entries, tha't still not really be a solution. If
> > that's not what you mean, sorry - and nice that we agree ;)
> >
> >
>
> Just to keep things sane I would like to remind that in this concrete
> patch there _are_ catalog entries:
>
> ```
> [...]
> This file contents imlementation of special type of temporary tables ---
> fast temporary tables (FTT). From user perspective they work exactly as
> regular temporary tables. However there are no records about FTTs in
> pg_catalog. These records are stored in backend's memory instead and
> mixed with regular records during scans of catalog tables. We refer to
> corresponding tuples of catalog tables as "in-memory" or "virtual"
> tuples and to all these tuples together --- as "in-memory" or "virtual"
> catalog.
> [...]
> ```
>
> As Tom pointed out a lot of PL/pgSQL code would stop working otherwise.
> Also I mentioned that in this case even \d and \d+ would not work.
>
> I personally find this discussion very confusing. Maybe we should
> concentrate on a concrete patch instead of some abstract ideas and
> topics that are still open.
>
> For instance it surprises me that apparently there is no one who
> objects "lets make all temporary tables fast temporary tables" idea.
> Since in this case code would use more memory for keeping a virtual
> catalog wouldn't it be considered a major change of behavior that could
> break someones production environment?
>

It is pretty hard discussion about cost or usability of FTT. The small FTT
(for usage in PLpgSQL) can be replaced by arrays. The overhead of
pg_catalog of big TT is not significant. So introduction special
proprietary table type is debatable.

Probably size of metadata of temporary tables should be minimal - currently
all metadata are cached in memory - and it is not a problem.

But we can change this discussion little bit different. I believe so
solution should be *global temporary tables*. These tables has persistent
catalogue entries. Data are joined with session. These tables can be
effective solution of problem with temporary tables, can be strong benefit
for developers (more comfortable, possible static analyse of PLpgSQL) and
it simplify life to all people who has do migration from Oracle. So only
benefits are there :).

Regards

Pavel

>
> --
> Best regards,
> Aleksander Alekseev
>