On Tue, Aug 11, 2020 at 4:46 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
A GIN index on an hstore column only provides the ability to search for
exact matches to hstore key strings. There are a few bells and whistles,
like the ability to AND or OR such conditions. But basically it's just an
exact-match engine, and it doesn't index the hstore's data values at all
(which is why the implementors weren't too concerned about having a length
limit on the index entries). There is 0 chance of this index type being
useful for what the OP wants to do.
Thanks for sharing. More like json path ops and not the full key and value. Interesting.
Another point is that you will only
get an indexscan if *every* OR'd clause matches some index. The example
query looks sufficiently unstructured that that might be hard to ensure.
Does this still apply when the where clauses are on several tables and not just one?
