Horton
Menu

Re: Reduce build times of pg_trgm GIN indexes

David Geier <geidav.pg@gmail.com>

View thread
From: David Geier <geidav.pg@gmail.com>
To: John Naylor <johncnaylorls@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-13T15:05:30Z
Lists: pgsql-hackers 
On 08.04.2026 04:15, John Naylor wrote:
> 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?

Well spotted. Thanks!

> 
> No, it's quite recent:
> 
> https://www.postgresql.org/message-id/20240212230423.GA3519%40nathanxps13

In my original benchmarks it was faster. I'll rebase the remaining
commits and do some more analysis.

--
David Geier

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