Re: [Proposal] Global temporary tables

čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik <
k(dot)knizhnik(at)postgrespro(dot)ru> napsal:

>
>
> On 30.01.2020 12:23, Pavel Stehule wrote:
>
>
> Building regular index requires two kinds of lock:
>> 1. You have to lock pg_class to make changes in system catalog.
>> 2. You need to lock heap relation to pervent concurrent updates while
>> building index.
>>
>> GTT requires 1) but not 2).
>> Once backend inserts information about new index in system catalog, all
>> other sessions may use it. pg_class lock prevents any race condition here.
>> And building index itself doesn't affect any other backends.
>>
>
> It is true. The difference for GTT, so any other sessions have to build
> index (in your proposal) as extra operation against original plan.
>
> What is "index"?
> For most parts of Postgres it is just an entry in system catalog.
> And only executor deals with its particular implementation and content.
>
> My point is that if we process GTT index metadata in the same way as
> regular index metadata,
> then there will be no differences for the postgres between GTT and regular
> indexes.
> And we can provide the same behavior.
>

There should be a difference - index on regular table is created by one
process. Same thing is not possible on GTT. So there should be a difference
every time.

You can reduce some differences, but minimally me and Robert don't feel it
well. Starting a building index from routine, that is used for reading from
buffer doesn't look well. I can accept some stranges, but I need to have
feeling so it is necessary. I don't think so it is necessary in this case.

Regards

Pavel

> Concerning actual content of the index - it is local to the backend and it
> is safe to construct it a t any point of time (on demand).
> It depends only on private data and can not be somehow affected by other
> backends (taken in account that we preserve locking policy of regular
> tables).
>
>
> --
> Konstantin Knizhnik
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>