Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements
От | Mihail Nikalayeu |
---|---|
Тема | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
Дата | |
Msg-id | CADzfLwXocKhpW3eFP1oScz+m+1XJ3bpi9QmVpoqC9RX9oyX=UA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements (Sergey Sargsyan <sergey.sargsyan.2001@gmail.com>) |
Список | pgsql-hackers |
Hello, Sergey! > I think it's to avoid duplicate errors when adding tuples from STIP to the main index, > but couldn't we just suppress that error during validation and skip the new tuple insertion if it already exists? In some cases, it is not possible: – Some index types (GiST, GIN, BRIN) do not provide an easy way to detect such duplicates. – When we are building a unique index, we cannot simply skip duplicates, because doing so would also skip the rows that should prevent the unique index from being created (unless we add extra logic for B-tree indexes to compare TIDs as well). > The main index may get huge after building, and iterating over it in a single thread and then sorting tids can be timeconsuming. My tests indicate that the overhead is minor compared with the time spent scanning the heap and building the index itself. > At least I guess one can skip it when STIP is empty. Yes, that’s a good idea; I’ll add it later. > p.s. I noticed that `stip.c` has a lot of functions that don't follow the Postgres coding style of return type on separateline. Hmm... I’ll fix that as well. Best regards, Mikhail.
В списке pgsql-hackers по дате отправления: