On Wed, Oct 14, 2015 at 4:06 PM, Robert Haas <robertmh...@gmail.com> wrote:

> 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,
> >
> > GET DIAGNOSTICS var = DID_I_MISS_ANYTHING_FROM_OTHER_SESSIONS;
> >
> > 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.
>
>
Hi Robert,

As usual, a great guidance from you. Thanks :-)

But I'm still trying to see, is there a way we can implement this for all
use cases.
Will update this thread with my findings.


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



-- 

Regards,
Dinesh
manojadinesh.blogspot.com

Reply via email to