Question regarding specifics of GIN and pg_trgm performance and potential use of show_trgm to improve it

Hello PostgreSQL community,

I am trying to improve performance of using similarity based queries on a large datasets and I would like to confirm my understanding of how GIN indexes work and how pg_trgm uses them.

If I understand it correctly, using GIN index is always a two step process: first, potential matches are searched in the index; then as a second step tuples are actually fetched and rechecked if they really match the query. This two step process can lead to degraded performance when the index scan matches too many elements that then are read from disk only to be dropped as non-matching during the recheck phase. Is that understanding correct?

Now to the issue... pg_trgm's similarity search can use similarity operator % to search for "similar" documents. Concept of "similarity" is based on a similarity of trigram array extracted from the query string and trigram arrays of searched values. This concept is quite tricky in a sense that just by matching trigrams in GIN index PostgreSQL can not tell if the final value will match or not as it does not know how many trigrams overall are there in that value... 

Consider following example:

If I understand this correctly the index scan really matches all 100000 items that are then read from disk only to be discarded during the recheck. So 2 seconds of doing all that work to return zero results (and I was lucky in my example to only have shared buffer hits, so no real disk I/O).

Is my understanding correct that this happens only because pg_trgm is not able to actually determine if the matched item from the index search is actually much much longer than the query? Is there any way how the performance can be improved in this case? I thought that I can store number of trigrams in the index, but that is not being used by the query planner:

Thank you for any sort of insight into this.

Regards,

Pavel