Re: Global temporary tables

>
>
> On Fri, 16 Aug 2019 at 15:30, Konstantin Knizhnik <
> k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>
>
>> I forget or do not notice some of your questions, would you be so kind as
>> to repeat them?
>>
>
>

Sent early by accident.

Repeating questions:

Why do you need to do all this indirection with changing RelFileNode to
RelFileNodeBackend in the bufmgr, changing BufferGetTag etc? Similarly,
your changes of RelFileNodeBackendIsTemp to RelFileNodeBackendIsLocalTemp .
I'm guessing you did it the way you did instead to lay the groundwork for
cross-backend sharing, but if so it should IMO be in your second patch that
adds support for using shared_buffers for temp tables, not in the first
patch that adds a minimal global temp tables implementation. Maybe my
understanding of the existing temp table mechanics is just insufficient as
I see RelFileNodeBackendIsTemp is already used in some aspects of existing
temp relation handling.

Did you look into my suggestion of extending the relmapper so that global
temp tables would have a relfilenode of 0 like pg_class etc, and use a
backend-local map of oid-to-relfilenode mappings?

Similarly, TruncateSessionRelations probably shouldn't need to exist in
this patch in its current form; there's no shared_buffers use to clean and
the same file cleanup mechanism should handle both session-temp and
local-temp relfilenodes.

Sequence initialization ignores sequence startval/firstval settings. Why?
+ value[SEQ_COL_LASTVAL-1] = Int64GetDatumFast(1); /* start
sequence with 1 */

Doesn't this change the test outcome for RELPERSISTENCE_UNLOGGED?:
- else if (newrelpersistence == RELPERSISTENCE_PERMANENT)
+ else if (newrelpersistence != RELPERSISTENCE_TEMP)

--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise