From: | Rick Otten <rottenwindfish(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 |
Subject: | Re: Performant queries on table with many boolean columns |
Date: | 2016-04-20 21:07:27 |
Message-ID: | CAMAYy4Krf1b3Lgz42-nAKYCSAfErhJospJp87yG5_HqkZCVO8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Would a bit string column work? --
http://www.postgresql.org/docs/9.5/static/datatype-bit.html
You might need to use a lot of bitwise OR statements in the query though if
you are looking at very sparse sets of specific values...
Something like the get_bit() function might allow you to select a specific
bit, but then you might want a bunch of functional indexes on the column
for various get_bit() combinations.
Maybe you can group commonly queried sets of columns into bit strings.
(rather than having one bit string column for all 100 booleans).
On Wed, Apr 20, 2016 at 2:54 PM, 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
>
>
> --
> Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
> WWW: http://www.sigaev.ru/
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-04-20 21:49:10 | Re: Performant queries on table with many boolean columns |
Previous Message | Teodor Sigaev | 2016-04-20 18:54:54 | Re: Performant queries on table with many boolean columns |