Marko Tiikkaja <ma...@joh.to> writes: > The LIMIT part *has* to happen after the rows have been locked or it > will work very surprisingly under concurrency (sort of like how FOR > SHARE / FOR UPDATE worked before 9.0).
Good point. > So either it has to be inside > ModifyTable or the ModifyTable has to somehow pass something to a Limit > node on top of it ... or we add a LockRows node below the Limit node. Yeah, that would make UPDATE/LIMIT a tad slower, but I think that might be preferable to what you're proposing anyway. Raw speed of what is fundamentally a fringe feature ought not trump every other concern. > This is just my personal opinion, but what I think should happen is: > 1) We put the LIMIT inside ModifyTable like this patch does. This > doesn't prevent us from doing ORDER BY in the future, but helps numerous > people who today have to > 2) We allow ORDER BY on tables with no inheritance children using > something similar to Rukh's previous patch. > 3) Someone rewrites how UPDATE works based on Tom's suggestion here: > http://www.postgresql.org/message-id/1598.1399826...@sss.pgh.pa.us, > which allows us to support ORDER BY on all tables (or perhaps maybe not > FDWs, I don't know how those work). The LIMIT functionality in this > patch is unaffected. I still think we should skip #2 and go directly to work on #3. Getting rid of the unholy mess that is inheritance_planner would be a very nice thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
