Horton
Menu

Re: Parallel CREATE INDEX for GIN indexes

Kirill Reshke <reshkekirill@gmail.com>

View thread
From: Kirill Reshke <reshkekirill@gmail.com>
To: Tomas Vondra <tomas@vondra.me>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-17T11:32:30Z
Lists: 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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Exercise parallel GIN builds in regression tests

  2. Lookup the correct ordering for parallel GIN builds

  3. Fix memory leak in _gin_parallel_merge

  4. Enforce memory limit during parallel GIN builds

  5. Compress TID lists when writing GIN tuples to disk

  6. Allow parallel CREATE INDEX for GIN indexes