| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel CREATE INDEX for GIN indexes |
| Date: | 2026-01-17 11:32:30 |
| Message-ID: | CALdSSPj+MfV7Aa6iBq9yh6uQXroit9gEUyNJFVK5Yg95NruD2A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 17 Jan 2026 at 00:07, Tomas Vondra <tomas(at)vondra(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-01-17 12:37:38 | Re: Row pattern recognition |
| Previous Message | Kirill Reshke | 2026-01-17 10:57:30 | Cleanup palloc'd structs on soft error path in `record_in` |