On Wed, Oct 14, 2015 at 4:06 PM, Robert Haas wrote:
> On Wed, Oct 14, 2015 at 6:28 PM, dinesh kumar
> 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 se
On Wed, Oct 14, 2015 at 6:28 PM, dinesh kumar 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 L
Hi Robert,
On Wed, Oct 14, 2015 at 12:56 PM, Robert Haas wrote:
> On Tue, Oct 13, 2015 at 10:37 PM, dinesh kumar
> wrote:
> > In an existing wait policies like WAIT(default) and NO WAIT,
> > one can be sure to determine(Using ROW_COUNT daignostics counter),
> > how many required tuples he proce
On Tue, Oct 13, 2015 at 10:37 PM, dinesh kumar wrote:
> In an existing wait policies like WAIT(default) and NO WAIT,
> one can be sure to determine(Using ROW_COUNT daignostics counter),
> how many required tuples he processed in a transaction.
> But this is not case when it comes to SKIP LOCKED.
On Tue, Oct 13, 2015 at 5:53 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
>
>>> > Using this attribute, we can have more control on parallel operations
>>> like,
>>>
>>> > IF SKIPPED_ROW_COUNT =0 THEN
>>> > <>
>>> > ELSE
>>> > <>
>>> > END IF;
>>>
>>> Um ... so what? This is not a u
>
>
>> > Using this attribute, we can have more control on parallel operations
>> like,
>>
>> > IF SKIPPED_ROW_COUNT =0 THEN
>> > <>
>> > ELSE
>> > <>
>> > 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 LO
On Mon, Oct 12, 2015 at 9:38 PM, Tom Lane wrote:
> dinesh kumar 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
dinesh kumar 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 be
Hi Team,
Would like to propose a new DIAGNOSTICS attribute, which returns the no.of
rows got skipped during the FOR UPDATE SKIP LOCKED;
Using this attribute, we can have more control on parallel operations like,
IF SKIPPED_ROW_COUNT =0 THEN
<>
ELSE
<>
END IF;
Kindly let me know your inputs/sugg
