> The main problem is likely to be that there is already a really good
> index type for speeding up equality queries (btree), and adding
> another (generally much worse) alternative is likely to confuse the
> planner more than anything. Is it really worth taking the performance
> hit on executing the equality query in order to avoid just keeping a
> second btree index?
I don't think it is a problem. I think btree would usually have lower
cost than GIN and therefore would be preferred by the planner. The
other opclasses are providing operators for such cases. For example,
range_ops(GiST) supports =, inet_ops(GiST) supports all basic
comparisons.
It is likely that pg_trgm index created for pattern matching would be
sufficient for equality for some users. We shouldn't force them to
create an additional btree index.
> If I could somehow turn this into an extension module that installed
> with pg_trgm as a dependency, rather than reaching into pg_trgm's
> internals, then it might be worthwhile putting something like this on
> PGXN. But I don't know how to do that. And it doesn't seem
> worthwhile to change pg_trgm itself in this way.
I don't think it is useful to have such a small extension, even if it
would be possible.
> But in any case, it isn't a bug that pg_trgm doesn't do everything it
> theoretically could do.
I agree. Maybe we can add it to the next commitfest?
