On Mon, Oct 12, 2015 at 9:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> dinesh kumar <dineshkuma...@gmail.com> writes:
> > Would like to propose a new DIAGNOSTICS attribute, which returns the
> no.of
> > rows got skipped during the FOR UPDATE SKIP LOCKED;
>
> I'm concerned that there may not be any implementation-independent
> definition of this. That is, the query plan might or might not reject
> rows before the locking step is reached, which would result in
> random-looking changes in the output of the proposed counter.
>
> Constraining the query plan might fix that, but only at unacceptable
> performance costs, especially since those constraints would have to apply
> to every plan ever generated (since the query planner can't know whether
> you will inquire about this counter value later).
>
>
Thanks Tom. Understood.
> > Using this attribute, we can have more control on parallel operations
> like,
>
> > IF SKIPPED_ROW_COUNT =0 THEN
> > <<Treat me as, a complete transaction, and do below stuff>>
> > ELSE
> > <<Got only few tuples than required, and do below stuff>>
> > END IF;
>
> Um ... so what? This is not a use-case.
>
>
In my view, "How one can be sure that, he obtained all the tuples with SKIP
LOCKED". If the end user has this counter value, he may proceed with a
different approach with partially locked tuples.
regards, tom lane
>
--
Regards,
Dinesh
manojadinesh.blogspot.com
