| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Rob Imig <rimig88(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Performant queries on table with many boolean columns |
| Date: | 2016-04-21 16:45:56 |
| Message-ID: | CAMkU=1xXXANTYp7YLQjjzvgYCFQsr+y6iTphx1Q4y8iP7QpRjw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Apr 20, 2016 at 11:54 AM, Teodor Sigaev <teodor(at)sigaev(dot)ru> wrote:
>>
>> The obvious thing seems to make a table with ~100 columns, with 1 column
>> for each boolean property. Though, what type of indexing strategy would
>> one use on that table? Doesn't make sense to do BTREE. Is there a better
>> way to structure it?
>>
> looks like a deal for contrib/bloom index in upcoming 9.6 release
Not without doing a custom compilation with an increased INDEX_MAX_KEYS:
ERROR: cannot use more than 32 columns in an index
But even so, I'm skeptical this would do better than a full scan. It
would be interesting to test that.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rob Imig | 2016-04-21 19:34:52 | Re: Performant queries on table with many boolean columns |
| Previous Message | Jeff Janes | 2016-04-21 16:36:37 | Re: Performant queries on table with many boolean columns |