From: | Floris Van Nee <florisvannee(at)Optiver(dot)com> |
---|---|
To: | "'pgsql-general(at)lists(dot)postgresql(dot)org'" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | GIN multi-column index |
Date: | 2018-10-03 13:10:24 |
Message-ID: | 2312f8d2fb514fb38dc5c33ec9db5f38@opammb0562.comp.optiver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
I've been looking at using GIN indices in some of my tables and was wondering something about their behavior when using them as a multi-column index. Suppose we have a table 't' with column 'a' as int and column 'b' as int[]. Suppose we also have a query like:
select * from t where a=1 and b@>'{2}'
If I define a GIN index on (a, b) (with contrib extension btree_gin), will this be a significant improvement over a GIN index just on b (significant meaning, a similar improvement to what you would expect for a btree multi-column index in a similar situation where the equality is tested on first column and the second column is an inequality)? I know in a btree index the speedup is generally significant as long as your left-most index column has an equality comparison, due to the way btree indices work. But I couldn't find information in the docs on how GIN indices behave in such a situation and why.
-Floris
From | Date | Subject | |
---|---|---|---|
Next Message | David Gauthier | 2018-10-03 15:46:05 | Re: How can I get and handle the status of sql statements that run in plpgsql ? |
Previous Message | Chris Travers | 2018-10-03 13:03:48 | Re: DB size difference after restore |