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?
From:
Jim Jarvie Date: Subject:
Re: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"?
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
✖
By continuing to browse this website, you agree to the use of cookies. Go to Privacy Policy.