From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kiriakos Georgiou <kg(dot)postgresql(at)olympiakos(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: order of evaluation of search arguments |
Date: | 2012-02-16 05:44:16 |
Message-ID: | 1122.1329371056@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kiriakos Georgiou <kg(dot)postgresql(at)olympiakos(dot)com> writes:
> As I understand it the order the of evaluation of search arguments is up to the optimizer. I've tested the following query, that is supposed to take advantage of advisory locks to skip over rows that are locked by other consumers running the exact same query and it seems to work fine. It seems to me the optimizer should always prefer to scan by status. What say you?
"When it breaks, you get to keep both pieces." Was your testing even
capable of noticing the problem if the query locked more rows than you
wanted?
Less dangerous coding practices might involve putting the lock function
in an outer query, while using an OFFSET 0 in the sub-query as an
optimization fence.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Venkat Balaji | 2012-02-16 06:21:02 | Re: [GENERA]: Postgresql-9.1.1 synchronous replication issue |
Previous Message | John R Pierce | 2012-02-16 05:32:46 | Re: Postgres 9.1 package for i.MX51X processor from Freescale |