Re: Possible future performance improvement: sort updates/deletes by ctid

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Possible future performance improvement: sort updates/deletes by ctid
Дата
Msg-id 2356.1201667979@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Possible future performance improvement: sort updates/deletes by ctid  ("Stephen Denne" <Stephen.Denne@datamail.co.nz>)
Ответы Re: Possible future performance improvement: sort updates/deletes by ctid  ("Stephen Denne" <Stephen.Denne@datamail.co.nz>)
Список pgsql-hackers
"Stephen Denne" <Stephen.Denne@datamail.co.nz> writes:
> How hard is it to match, recognise potential benefit, and rewrite the query from

> UPDATE ONLY document_file AS df SET document_type_id = 
>         d.document_type_id FROM document AS d WHERE d.id = document_id;

> to

> UPDATE ONLY document_file AS df SET document_type_id = 
> (SELECT d.document_type_id FROM document AS d WHERE d.id = document_id);

> Which is several orders of magnitude faster for me.

At the planner level that would be entirely the wrong way to go about
it, because that's forcing the equivalent of a nestloop join, which is
very unlikely to be faster for the numbers of rows that we're talking
about here.  The reason it looks faster to you is that the benefits of
updating the document_file rows in ctid order outweigh the costs of the
dumb join strategy ... but what we want to achieve here is to have both
benefits, or at least to give the planner the opportunity to make a
cost-driven decision about what to do.
        regards, tom lane


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

Предыдущее
От: "Stephen Denne"
Дата:
Сообщение: Re: Possible future performance improvement: sort updates/deletes by ctid
Следующее
От: "Stephen Denne"
Дата:
Сообщение: Re: Possible future performance improvement: sort updates/deletes by ctid