Marko Tiikkaja <marko@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.1399826841@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
