On Mon, Oct 26, 2009 at 10:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvhe...@commandprompt.com> writes: >> Tom Lane escribió: >>> Yeah, it could definitely run slower than the existing code --- in >>> particular the combination of all three (FOR UPDATE ORDER BY LIMIT) >>> would tend to become a seqscan-and-sort rather than possibly just >>> reading one end of an index. However, I quote the old aphorism that >>> it can be made indefinitely fast if it doesn't have to give the right >>> answer. The reason the current behavior is fast is it's giving the >>> wrong answer :-( > >> So this probably merits a warning in the release notes for people to >> check that their queries continue to run with the performance they >> expect. > > One problem with this is that there isn't any good way for someone to > get back the old behavior if they want to. Which might be a perfectly > reasonable thing, eg if they know that no concurrent update is supposed > to change the sort-key column. The obvious thing would be to allow > > select * from (select * from foo order by col limit 10) ss for update; > > to apply the FOR UPDATE last. Unfortunately, that's not how it works > now because the FOR UPDATE will get pushed down into the subquery. > I was shot down when I proposed a related change, a couple weeks ago > http://archives.postgresql.org/message-id/7741.1255278...@sss.pgh.pa.us > but it seems like we might want to reconsider.
"Shot down" might be an overstatement of the somewhat cautious reaction that proposal. :-) Could the desired behavior be obtained using a CTE? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
