Re: [Proposal] Global temporary tables - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: [Proposal] Global temporary tables
Date
Msg-id e78afd0d-124c-11f3-e320-de3089fa5c3b@postgrespro.ru
Whole thread Raw
In response to Re: [Proposal] Global temporary tables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [Proposal] Global temporary tables  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers


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.

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 

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: [Proposal] Global temporary tables
Next
From: Pavel Stehule
Date:
Subject: Re: [Proposal] Global temporary tables