Re: Query on view radically slower than query on underlying table

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Query on view radically slower than query on underlying table
Дата
Msg-id 28838.1298923108@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Query on view radically slower than query on underlying table  (Craig James <craig_james@emolecules.com>)
Ответы Re: Query on view radically slower than query on underlying table  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
Craig James <craig_james@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
avoidingthat 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

В списке pgsql-performance по дате отправления:

Предыдущее
От: Craig James
Дата:
Сообщение: Re: Query on view radically slower than query on underlying table
Следующее
От: Selva manickaraja
Дата:
Сообщение: Re: Load and Stress on PostgreSQL 9.0