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.
