User-Agent: K-9 Mail for Android
In-Reply-To: 
 <CAMkU=1yxskTJ8ZQQZvBqJ82Jk_R_NoeuCKkYv+8aunT191=Htw@mail.gmail.com>
References: <53AB2CB1.8080201@comcast.net> <53AB35CC.10202@optionshouse.com>
 <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
 <CAMkU=1yxskTJ8ZQQZvBqJ82Jk_R_NoeuCKkYv+8aunT191=Htw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Subject: Re: how to improve perf of 131MM row table?
From: Aaron Weber <aweber@comcast.net>
Date: Thu, 26 Jun 2014 16:40:51 -0400
To: Jeff Janes <jeff.janes@gmail.com>
CC: Shaun Thomas <sthomas@optionshouse.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-ID: <69dfd7f3-ccbb-4ae9-97f0-fcb99e7c9c18@email.android.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org


>The PK of the master table and the PK of the detail table cannot be
>the same thing, or they would not have a master-detail relationship.
>One side has to be an FK, not a PK.
>
Of course this is correct. I was trying to make the point that there should be unique indices (of whatever flavor PG uses for PK's by default) on the relevant columns.  Since we're referring to a select statement, the actual integrity constraints should not come into play. 

I will remember to be more explicit about the schema next time. 


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