Re: [Proposal] Global temporary tables

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

>
>
> On 30.01.2020 12:52, Pavel Stehule wrote:
>
>
>
> č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.
>
>
> Metadata of GTT index is also created by one process. And actual content
> of the index is not interesting for most parts of Postgres.
>
>
> 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.
>
>
> Sorry, but "don't feel it well", "doesn't look well" looks more like
> literary criticism rather than code review;)
>

The design is subjective. I am sure, so your solution can work, like mine,
or any other. But I am not sure, so your solution is good for practical
usage.

> Yes, I agree that it is unnatural to call btindex from _bt_getbuf. But
> what can go wrong here?
>

creating index as side effect of table reading. Just the side effect too
much big.

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