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).
> 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.
regards, tom lane
