| От | Tom Lane |
|---|---|
| Тема | Re: Why are queries with subselects so slow? |
| Дата | |
| Msg-id | 195.1047048897@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Why are queries with subselects so slow? ("Robert Wille" <robertw@willeweb.com>) |
| Список | pgsql-general |
"Robert Wille" <robertw@willeweb.com> writes:
> [ this is awfully slow: ]
> update image set state =3D ((state & -35184340369664::int8) | 0::int8) wher=
> e containerid in (select containerid from ancestry where ancestorid =3D 122=
> 8067)
IN is notoriously slow. It'll be better in 7.4, but in the meantime
it's best avoided. It appears from your schema that the subselect
cannot generate duplicate containerids, so you should be able to do
it like this:
update image set state = ((state & -35184340369664::int8) | 0::int8)
from ancestry
where image.containerid = ancestry.containerid
and ancestry.ancestorid = 1228067;
regards, tom lane
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера