čt 30. 1. 2020 v 11:02 odesílatel Konstantin Knizhnik < k.knizh...@postgrespro.ru> napsal:
> > > On 30.01.2020 12:52, Pavel Stehule wrote: > > > > čt 30. 1. 2020 v 10:44 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.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 > >
