On Wed, Oct 14, 2015 at 6:28 PM, dinesh kumar <dineshkuma...@gmail.com> wrote:
> I see this feature as an add on to do the parallel DML operations.
> There won't be any problem, if operations are mutually exclusive.
> I mean, each session operates on unique set of tuples.
> In the above case, we don't even need of SKIP LOCKED wait policy.
> But, when it comes to mutually depend operations, isn't it nice to provide,
> how much were locked by the other sessions. OR atlest a HINT to the other
> session like,
> I agree that, adding counter will take a performance hit.
> Rather going to my actual proposal on providing the counter value,
> isn't it good to provide a boolean type HINT, if we miss atleast a single
> tuple.

Suppose there are 5 locked rows and 5 unlocked rows in the heap and you do this:

select * from t1 for share skip locked limit 5

The Boolean you propose will be false if the first 5 rows in physical
order are locked, and otherwise it will be false.  But there's no
difference between those two scenarios from the perspective of the
application.  Here's another example:

with foo as (select * from t1 for share skip locked) select * from foo
where a = 2;

If foo contains any locked rows at all, this will return true,
regardless of whether a = 2.

It's true that, for a lot of normal-ish queries, LockRows is applied
late enough that your proposed Boolean would return the intended
answer.  But there are a bunch of exceptions, like the ones shown
above, and there might be more in the future.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to