Re: [PROPOSAL] DIAGNOSTICS <var> = SKIPPED_ROW_COUNT

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: dinesh kumar <dineshkumar02(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PROPOSAL] DIAGNOSTICS <var> = SKIPPED_ROW_COUNT
Date: 2015-10-13 12:53:07
Message-ID: CAKFQuwYR0zOB9PZTky19BtMWBRCfZvsnp327fAUuNFLQYo4u=g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
>
>> > 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.
>
>
​Can you be more specific? In most cases I can come up with (queues,
basically) where skipped locked is running the processing performing the
query is going to re-query the database on the next tick regardless of
whether they thought they say only some or all of the potential rows on the
prior pass.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-10-13 13:04:26 Re: pg_ctl/pg_rewind tests vs. slow AIX buildfarm members
Previous Message Amir Rohan 2015-10-13 12:30:29 Re: Memory prefetching while sequentially fetching from SortTuple array, tuplestore