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).
