On Tue, Aug 11, 2020 at 4:46 PM Tom Lane <t...@sss.pgh.pa.us> 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?
