| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Rafal Pietrak <rafal(at)ztk-rp(dot)eu> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: FK v.s unique indexes |
| Date: | 2018-07-05 21:04:41 |
| Message-ID: | CAKFQuwatvdZ5xfLVa8h5P9ThaPuoKrUwYG5M2GErh+V7Pq18VA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Jul 5, 2018 at 1:45 PM, Rafal Pietrak <rafal(at)ztk-rp(dot)eu> wrote:
> I was thinking, that when "add constraint" cannot choose appropriate
> index, may be some explicit help (like ... using <index_name>;) would be
> due.
>
Basically all the FK trigger does is:
SELECT EXISTS(SELECT 1 FROM pk_table WHERE pk_col1 = val1 AND pk_col2 =
val2)
And fails if query returns false. The planner is still free to use the
index or not to execute the query just as if you had written it by hand.
For a small table fully in memory it likely would prefer a sequential scan
and it would be perfectly within its rights to do so.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafal Pietrak | 2018-07-05 21:36:45 | Re: FK v.s unique indexes |
| Previous Message | Rafal Pietrak | 2018-07-05 21:02:30 | Re: FK v.s unique indexes |