Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aszN7-0003ui-VU for pgsql-performance@arkaria.postgresql.org; Wed, 20 Apr 2016 21:09:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1aszN6-00071i-PH for pgsql-performance@arkaria.postgresql.org; Wed, 20 Apr 2016 21:09:16 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1aszLP-0005B8-Qr for pgsql-performance@postgresql.org; Wed, 20 Apr 2016 21:07:32 +0000 Received: from mail-vk0-x230.google.com ([2607:f8b0:400c:c05::230]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1aszLM-00070E-SL for pgsql-performance@postgresql.org; Wed, 20 Apr 2016 21:07:30 +0000 Received: by mail-vk0-x230.google.com with SMTP id t129so75014864vkg.2 for ; Wed, 20 Apr 2016 14:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tfXT56dzP7NNNZO035EX4qp6YfIexB4BTiigzGo4rZ4=; b=mBIxF66WpjuDfDJVvUgOyPb8uV+AUQmMLfNWVkc8xOT8AzxlmRxgYyUq5aj2nO3T0Y k8J37D6fQEb2+Y0rv/6M64s3i61DIIZvn2wp/tkK2jmXBpM6ESe0AXNSvBUlrwGNjpVN Tnp0MlK0ZY/b96YMWGoSfEWyd+IPBbTAMJn0CioytthxnUy2hAZYzOzKqMC8fPoLUYMd lJqGRYv0KZtq7b0mFNxHarRg9PmAXERIl393JCoZy5LduaCLNFMQHwBWv0HQTSmNOmd6 IVVyZLCwQdUBdhSchwuJaJnK/Dnx9MgGj553VXWZ72dEmP6wo0MNy/h3T9cUiw+h18/k /UCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tfXT56dzP7NNNZO035EX4qp6YfIexB4BTiigzGo4rZ4=; b=eANdfCXKf55a4B94Tu2+8kJWvRlqRQjKnVTV2zXFBUMJ0wsou39W75Suq+yGOmfjbP 3hZ0RKDMGsCt/9VdsjolKe5r64URH87YeBR7/qvXZQpYn+sMGe2ZTDC3dfJTwVZly1H4 2qQMr+/OZbOsfmg5HdkTOciL70sOUat5VH6DLUQRv7mswNcw8iQn0edHH8O5XBm/8qxn 7RxESNeOugAysJcqLqSJotO1B+DAjvsQJ5A0JrD288Z6KbcYUdMyRUA+K/741ZZWqPoT NIcWGIZJy8JLdoI+2nObyeZQiHnHYQYN6Ouwbb8b5abj4Lnf/9RHq2PbVHlMYJnY1snD yIRA== X-Gm-Message-State: AOPr4FXjJO8Y/Sq2h8TpFcKvjowhAFB8MgHARgxeqS8UsS+i6XYiaITElps5TFiiDfWDTyOJ5pXBwAdSZ7zmwA== MIME-Version: 1.0 X-Received: by 10.31.8.205 with SMTP id 196mr5918887vki.144.1461186447665; Wed, 20 Apr 2016 14:07:27 -0700 (PDT) Received: by 10.31.179.11 with HTTP; Wed, 20 Apr 2016 14:07:27 -0700 (PDT) In-Reply-To: <5717D07E.3070802@sigaev.ru> References: <5717D07E.3070802@sigaev.ru> Date: Wed, 20 Apr 2016 17:07:27 -0400 Message-ID: Subject: Re: Performant queries on table with many boolean columns From: Rick Otten To: Teodor Sigaev Cc: Rob Imig , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=001a1144f91229f23a0530f0fb5c X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a1144f91229f23a0530f0fb5c Content-Type: text/plain; charset=UTF-8 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 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@sigaev.ru > WWW: http://www.sigaev.ru/ > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > --001a1144f91229f23a0530f0fb5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Would a bit string column work? --=C2=A0http://www.postgresql= .org/docs/9.5/static/datatype-bit.html=C2=A0

You mig= ht need to use a lot of bitwise OR statements in the query though if you ar= e looking at very sparse sets of specific values...

Something like the get_bit() function might allow you to select a specifi= c 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. =C2=A0(rather than= having one bit string column for all 100 booleans).



On Wed, Apr 20, 2016 at 2:54 PM, Teodor Sigaev <teodor@sigaev.ru><= /span> 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 bette= r
way to structure it?

looks like a deal for contrib/bloom index in upcoming 9.6 release


--
Teodor Sigaev=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 E-mail: teodor@sigaev.ru
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WWW: http://www.sig= aev.ru/


--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-perform= ance

--001a1144f91229f23a0530f0fb5c--