On Mon, Oct 12, 2015 at 9:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
dinesh kumar <dineshkumar02@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.