Re: Supporting = operator in gin/gist_trgm_ops
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-26T17:50:05Z
Lists: pgsql-hackers
On Mon, Oct 26, 2020 at 7:38 AM Julien Rouhaud <rjuju123@gmail.com> wrote: > Ah, yes this might lead to bad performance if the "fake wildcard" > matches too many rows, but this shouldn't be a very common use case, > and the only alternative for that might be to create trigrams for non > alphanumerics characters. I didn't try to do that because it would > mean meaningful overhead for mainstream usage of pg_trgm, and would > also mean on-disk format break. In my opinion supporting = should be > a best effort, especially for such corner cases. It would be more efficient to generate trigrams for equal operator using generate_trgm() instead of generate_wildcard_trgm(). It some cases it would generate more trigrams. For instance generate_trgm() would generate '__a', '_ab', 'ab_' for '%ab%' while generate_wildcard_trgm() would generate nothing. Also I wonder how our costing would work if there are multiple indices of the same column. We should clearly prefer btree than pg_trgm gist/gin, and I believe our costing provides this. But we also should prefer btree_gist/btree_gin than pg_trgm gist/gin, and I'm not sure our costing provides this especially for gist. ------ Regards, Alexander Korotkov
Commits
-
Reword 'simple comparison' => 'inequality' in pgtrgm.sgml
- 7adb8feb0f69 14.0 landed
-
Add missing 'the' to pgtrgm.sgml
- b7edb5d96e7c 14.0 landed
-
Handle equality operator in contrib/pg_trgm
- 935f66665022 14.0 landed