MIME-Version: 1.0
In-Reply-To: <5717D07E.3070802@sigaev.ru>
References: 
 <CANcrS5pR1P1Tj=e-RQQ=FF3WPAy_fyruS0YJer-+iJHxR1JAiA@mail.gmail.com>
	<5717D07E.3070802@sigaev.ru>
Date: Wed, 20 Apr 2016 14:49:10 -0700
Message-ID: 
 <CAKFQuwY3z7oGwriDie4guGPudy_k8S4wWJKrTRy7zPKjTUm=wQ@mail.gmail.com>
Subject: Re: Performant queries on table with many boolean columns
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Rob Imig <rimig88@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Content-Type: multipart/alternative; boundary=001a113734c25ae9f50530f190be
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

--001a113734c25ae9f50530f190be
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 20, 2016 at 11:54 AM, Teodor Sigaev <teodor@sigaev.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


=E2=80=8BCurious, it doesn't look like it will work with booleans out of th=
e box.

http://www.postgresql.org/docs/devel/static/bloom.html

David J.
=E2=80=8B

--001a113734c25ae9f50530f190be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif"><span style=3D"font-family:arial,sans-serif">On Wed, Ap=
r 20, 2016 at 11:54 AM, Teodor Sigaev </span><span dir=3D"ltr" style=3D"fon=
t-family:arial,sans-serif">&lt;<a href=3D"mailto:teodor@sigaev.ru" target=
=3D"_blank">teodor@sigaev.ru</a>&gt;</span><span style=3D"font-family:arial=
,sans-serif"> wrote:</span><br></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span class=3D""><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The obvious thing seems to make a table with ~100 columns, with 1 column<br=
>
for each boolean property. Though, what type of indexing strategy would<br>
one use on that table? Doesn&#39;t make sense to do BTREE. Is there a bette=
r<br>
way to structure it?<br>
<br>
</blockquote></span>
looks like a deal for contrib/bloom index in upcoming 9.6 release</blockquo=
te><div><br></div><div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;display:inline">=E2=80=8BCurious, it doesn&#39;t l=
ook like it will work with booleans out of the box.</div></div><div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;displ=
ay:inline"><br></div></div><div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif;display:inline"><a href=3D"http://www.pos=
tgresql.org/docs/devel/static/bloom.html">http://www.postgresql.org/docs/de=
vel/static/bloom.html</a></div></div><div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;display:inline"><br></div></div=
><div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;display:inline">David J.</div></div><div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;display:inline">=E2=80=
=8B</div>=C2=A0</div></div></div></div>

--001a113734c25ae9f50530f190be--