Craig James <craig_ja...@emolecules.com> writes:
> Then I thought maybe putting a foreign-key constraint on table "my_version"
> would solve the problem:
> alter table my_version add constraint fk_my_view foreign key(version_id)
> references registry.version(version_id) on delete cascade;
> That way, the planner would know that every key in table "my_version" has to
> also be in table "version", thus avoiding that part about "forcing the other
> join to be done in toto". But the foreign-key constraint makes no
> difference, it still does the full join and takes 65 seconds.
That's just wishful thinking I'm afraid. The planner doesn't currently
make any deductions whatsoever from the presence of a foreign key
constraint; and even if it did, I'm not sure that this would help it
decide that a join order constraint could safely be dropped.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
