Re: Reduce build times of pg_trgm GIN indexes

John Naylor <johncnaylorls@gmail.com>

From: John Naylor <johncnaylorls@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: David Geier <geidav.pg@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-08T02:15:38Z
Lists: pgsql-hackers
On Tue, Apr 7, 2026 at 6:27 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> But the comments on the pg_cmp functions say:
>
> >  * NB: If the comparator function is inlined, some compilers may produce
> >  * worse code with these helper functions than with code with the
> >  * following form:
> >  *
> >  *     if (a < b)
> >  *         return -1;
> >  *     if (a > b)
> >  *         return 1;
> >  *     return 0;
> >  *
>
> So, uh, is that really a universal improvement? Is that comment about
> producing worse code outdated?

No, it's quite recent:

https://www.postgresql.org/message-id/20240212230423.GA3519%40nathanxps13

--
John Naylor
Amazon Web Services



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Change PointerGetDatum() back to a macro

  2. Replace deprecated StaticAssertStmt() with StaticAssertDecl()

  3. Optimize sorting and deduplicating trigrams

  4. Optimize sort and deduplication in ginExtractEntries()

  5. Inline ginCompareAttEntries for speed