| From: | Aaron Weber <aweber(at)comcast(dot)net> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Shaun Thomas <sthomas(at)optionshouse(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: how to improve perf of 131MM row table? |
| Date: | 2014-06-26 20:40:51 |
| Message-ID: | 69dfd7f3-ccbb-4ae9-97f0-fcb99e7c9c18@email.android.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
>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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aaron Weber | 2014-06-26 20:43:47 | Re: how to improve perf of 131MM row table? |
| Previous Message | Shaun Thomas | 2014-06-26 20:26:43 | Re: how to improve perf of 131MM row table? |