Re: [Proposal] Global temporary tables

On 06.01.2020 8:04, 曾文旌(义从) wrote:
> In the previous communication
>
> 1 we agreed on the general direction
> 1.1 gtt use local (private) buffer
> 1.2 no replica access in first version
>
> 2 We feel that gtt needs to maintain statistics, but there is no agreement on what it will be done.
>
> 3 Still no one commented on GTT's transaction information processing, they include
> 3.1 Should gtt's frozenxid need to be care?
> 3.2 gtt’s clog clean
> 3.3 How to deal with "too old" gtt data
>
> I suggest we discuss further, reach an agreement, and merge the two patches to one.
>

I also hope that we should come to the common solution for GTT.
If we do not try to address parallel execution issues and access to temp
tables at replicas (and I agreed
that it should be avoided in first version of the patch), then GTT patch
becomes quite small.

The most complex and challenged task is to support GTT for all kind of
indexes. Unfortunately I can not proposed some good universal solution
for it.
Just patching all existed indexes implementation seems to be the only
choice.

Statistic is another important case.
But once again I do not completely understand why we want to address all
this issues with statistic in first version of the patch? It contradicts
to the idea to make this patch as small as possible.
Also it seems to me that everybody agreed that users very rarely create
indexes for temp tables and explicitly analyze them.
So I think GTT will be useful even with limited support of statistic. In
my version statistics for GTT is provided by pushing correspondent
information to backend's cache for pg_statistic table.
Also I provided pg_temp_statistic view for inspecting it by users. The
idea to make pg_statistic a view which combines statistic of normal and
temporary tables is overkill from my point of view.

I do not understand why do we need to maintain hash with some extra
information for GTT in backends memory (as it was done in Wenjing patch).
Also idea to use create extension for accessing this information seems
to be dubious.

--
Konstantin Knizhnik
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company