Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Дата
Msg-id 13436.1256580117@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> On Sun, Oct 25, 2009 at 7:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> All that we have to do to fix the first one is to put the LockRows node
>> below the Limit node instead of above it. �The solution for the second
>> one is to also put LockRows underneath the Sort node, and to regard its
>> output as unsorted so that a Sort node will certainly be generated.
>> (This in turn implies that we should prefer the cheapest-total plan
>> for the rest of the query.)

> I'm not following how this would work. Would it mean that every record
> would end up being locked?

In the case of LIMIT, no, because LIMIT doesn't fetch any more rows than
it needs from its input node.  In the case of ORDER BY, yes,
potentially.  So we might conceivably decide we should fix the first
issue and not the second.  However, I'd prefer to have a solution
whereby the query does what it appears to mean and you have to write
something more complicated if you want performance over correctness.
        regards, tom lane


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Parsing config files in a directory