| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | dinesh kumar <dineshkumar02(at)gmail(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, 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-14 19:56:46 |
| Message-ID: | CA+TgmoZhh+kBM494h_QyCySYUKzTis0CKWQ5SUuK7qAmCVJj3g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 13, 2015 at 10:37 PM, dinesh kumar <dineshkumar02(at)gmail(dot)com> 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.
Sure it is. You didn't process the ones that you skipped. This is no
different than if you say WHERE a = 5. Depending on plan choice and
table contents, you may have "skipped" a large number of rows where a
!= 5, or you may have skipped none at all.
> In my view, SKIP LOCKED is a nice feature, which gives only the available OR
> unlocked tuples.
> But those are not the complete required tuples for the given SQL statement.
> Isn't it ?!
They better be. If you wanted the locked tuples, you shouldn't have
asked to skip them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2015-10-14 19:57:48 | Re: Performance improvement for joins where outer side is unique |
| Previous Message | Robert Haas | 2015-10-14 19:52:34 | Re: pam auth - add rhost item |