Re: Parallel CREATE INDEX for GIN indexes
| От | Kirill Reshke |
|---|---|
| Тема | Re: Parallel CREATE INDEX for GIN indexes |
| Дата | |
| Msg-id | CALdSSPj+MfV7Aa6iBq9yh6uQXroit9gEUyNJFVK5Yg95NruD2A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel CREATE INDEX for GIN indexes (Tomas Vondra <tomas@vondra.me>) |
| Список | pgsql-hackers |
On Sat, 17 Jan 2026 at 00:07, Tomas Vondra <tomas@vondra.me> wrote: > > > Also, the fact that tuplesort_begin_index_gin is placed not inside > > src/backend/access/gin ... Is it a little awkward? I am not saying > > this is anything worth fixing, but functions like writetup_index_gin > > etc, not being inside `access/gin`, is it a layering violation? > > > > There's also tuplesort_begin_index_btree, tuplesort_begin_index_hash, > tuplesort_begin_index_gist and tuplesort_begin_index_brin. I don't think > this is a layering violation, it's simply "create a tuplesort tailored > for a specific index AM". Or from the other direction - we could move > this to individual index AMs, but then the index AMs would need to know > about tuplesort. Which seems strange. > Yes. But anyway, I think Index AM should provide some implementation of some interface, which tuplesort then uses. Anyway, this is another topic, not matter now. I did a second look at 0002. I did not find any real issue, but maybe state in the commit message, how exactly changing CREATE INDEX to CIC makes GIN parallel code path exercised. -- Best regards, Kirill Reshke
В списке pgsql-hackers по дате отправления: