Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0 - Mailing list pgsql-bugs

From Manu
Subject Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
Date
Msg-id 179035068842.432745.14403644565457508812@gmail.com
Whole thread
In response to Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0  (Palak Chaturvedi <chaturvedipalak1911@gmail.com>)
Responses Re: BUG #19701: GIN trigram index loses rows at similarity_threshold 0
List pgsql-bugs
Hi Palak,

Thanks for the review and for the row-set comparison.

On Fri, 25 Sept 2026, Palak Chaturvedi wrote:
> * Insert rows after creating the GIN index, then test an empty
>   query at threshold zero before and after pending-list cleanup.
>
> * Include strict-word similarity (<<%) at zero, with stored empty
>   strings and NULLs.

Both are in v2, attached.  The new test uses a small table holding
two words, two empty strings and a NULL, inserted after the GIN index
is created.  It runs % and <<%, with an empty and a non-empty query,
before and after gin_clean_pending_list().  It then rebuilds the index
as GiST and repeats the <<% queries.  I added 1000 rows before the
GiST build: with only five rows the index is a single leaf page, and
leaf pages were already correct.

Without the C changes, each of the eight GIN queries returns 0 or 1
row instead of 4, both before and after the cleanup, and the empty
<<% query on GiST returns 0 instead of 1004.  With them, pg_trgm's
tests pass.  I checked this on master (45da2c1d756) and on
REL_14_STABLE, where v2 also applies cleanly.

Regards,
Manu

Attachment

pgsql-bugs by date:

Previous
From: Ludvig Janiuk
Date:
Subject: Re: 42P16 error when dropping and adding column
Next
From: Manu
Date:
Subject: Re: autovacuum: automatically propagate updated parameters