Re: LIMIT for UPDATE and DELETE

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