Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwJib-0000Ls-Hi for pgsql-sql@arkaria.postgresql.org; Fri, 07 Apr 2017 02:33:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cwJib-0007cE-41 for pgsql-sql@arkaria.postgresql.org; Fri, 07 Apr 2017 02:33:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cwJhY-0003zK-6a for pgsql-sql@postgresql.org; Fri, 07 Apr 2017 02:32:40 +0000 Received: from mail-pg0-x232.google.com ([2607:f8b0:400e:c05::232]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cwJhV-0000u3-4N for pgsql-sql@postgresql.org; Fri, 07 Apr 2017 02:32:39 +0000 Received: by mail-pg0-x232.google.com with SMTP id x125so52390326pgb.0 for ; Thu, 06 Apr 2017 19:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=bXpbBbD0lQZe1fHDjGyls9muT/xhXRdzcXoPLAPcEgA=; b=q/OPMGYv+DR2Unh1pRlDwPAiV16oA/CJcGlHL3PRq8ms9BenpaXYpA/x6ypnNjIynn 1Igv0p2bFGYs2KPAq7bTkTgRmU4+XPyRXtedjN3N7YMkz9pz66OBh4bGAF5K0lP87Ixg Xgeme4EHwZatJ+lt9sXIfHctMZOpGMTq8XAn2O1JIiJCXJjaaGYzfABRkmNpvfzpGewr VaspnqfqlCsZtVOJQ9MoiVlG4DGR8cY3j4Vo8gauEcBvEgIdUxNwSApmfcRTqHRO+TMm M0mp7WXZYSnVo8iPtWj+GIVLCoEFnOn6+YhiYCECbi+TL/OmL9e9JOVsWmCN/eEtP3EF A8wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=bXpbBbD0lQZe1fHDjGyls9muT/xhXRdzcXoPLAPcEgA=; b=RrEVeSDO1q8dJ2Ij9RehSY6h4DJUdnBAbFgPKIxriwYn4z9CnysNe9FCkn02KNWqOP p6dBGplGSi63HoABTyog9u4ZISNn1GmPd0W+HA7G9c+QXyActsvcOhtaqDG7FDFVi2fq Sf7upaLKcUc0R9bpHmJVGqgnutIGcBW705kqltEwMlxXdqhW1n3CUVQOnRrNKWytodVe m/QWO9p+DdkIecUV15gZH6fPmQoe9zCareOjLEeiuVmnZnI5/N4FOgeSxpTXOgb2ds+U zN40uw2uD55fzciKL51PTGcCd+Lia6cZHB//JkkdB6VdtFKtaE4N3rEMrpiv/sh2KTDY V5WA== X-Gm-Message-State: AN3rC/5NFty9jdjB2oKueOnKYyD8U9m+4yTHrn/LhSa1QKpXiaxRXkX92xT/GYi7zYjBNQ== X-Received: by 10.84.168.5 with SMTP id e5mr1490547plb.155.1491532354703; Thu, 06 Apr 2017 19:32:34 -0700 (PDT) Received: from [192.168.1.100] (c-98-202-89-42.hsd1.ut.comcast.net. [98.202.89.42]) by smtp.gmail.com with ESMTPSA id h14sm5960773pgn.64.2017.04.06.19.32.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 19:32:33 -0700 (PDT) From: Rob Sargent Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 6 Apr 2017 20:32:31 -0600 Subject: death of array? Message-Id: <73B8E1AF-BD4A-4E6A-B192-8394D59EF47C@gmail.com> To: "pgsql-sql@postgresql.org" X-Mailer: Apple Mail (2.3273) X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org I believe I have an appropriate use[1] for an array column, but I=E2=80=99m= having a hard time using that array in a join clause. The SQL question is how to use an array value in the join clause? I=E2=80= =99m using postgres 9.6 on ubuntu 16.04 create table probandset (id UUID, probands UUID[]) create table segment(id uuid, chr int, sbp int, epb int, probandset_id) create table people_member(people_id uuid, person_id uuid) create table people(id uuid, name text) create table person(id uuid, name text) probandset.probands is a set of person.id I need to gather all segments whose probandset is within in a specified peo= ple. select s.* from segment s join probandset ps on s.probandset_id =3D ps.id --PROBLEM: WOULD LIKE SOMETHING BETTER THAN THE FOLLOWING: join (select id, unnest(probands) as proband from probandset as l) as pu = on s.probandset_id =3D pu.id join people_member pm on pu.proband =3D pm.person_id join people pl on pm.people_id =3D pl.id where pl.name =3D =E2=80=98target population name=E2=80=99 The query I have works (showing only half of it here) and I=E2=80=99m not p= ushing the performance of it too much right now as I=E2=80=99m more interes= ted in the SQL problem. However, I am getting a seq scan on people_member, = not surprisingly. People_member will be blocks of people, 50 to 1000 per b= lock and each block loaded in a single transaction, no editing: should this= be clustered (and reclustered)? Over time would the seq scan go away as pe= ople_member.people_id becomes more discriminating? (There is an index on pe= ople_member.people_id). A people has a know set of probands (and we need al= l subsets of those probands) Current discussions at our end on whether or not a probandset may be filled= with members of more than one people. If not I might be able to add peopl= e_id to probandset and I am home free. But that still doesn=E2=80=99t answer the SQL question. Thanks for reading, sorry it=E2=80=99s a tad wordy. rjs [1] I=E2=80=99m dealing with power sets. A given set of N element has 2**N = subsets and the number of subset grows exponentially (obviously). But to m= odel this =E2=80=98normally=E2=80=99 would require an even larger number of= subset member records. (That summation left to the student[2]). My choice= was to list each subset once with and array of elements. Still an exponen= tial problem, but only one exponential problem. It all breaks down somewhere between 20 and 30 elements but we'll burn that= bridge when we get there. [2] Something like the sum over i=3D0..N of ((N choose i) * i maybe? --=20 Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql