On 1/10/11 12:37 PM, "Kevin Grittner" wrote:
>Scott Carey wrote:
>
>> Often, the best query plans result from 'LEFT JOIN WHERE right
>> side is NULL' rather than NOT EXISTS however. I often get
>> performance gains by switching NOT EXISTS queries to LEFT JOIN
>> form.
>
>Even in 8.4 and lat
Scott Carey wrote:
> Often, the best query plans result from 'LEFT JOIN WHERE right
> side is NULL' rather than NOT EXISTS however. I often get
> performance gains by switching NOT EXISTS queries to LEFT JOIN
> form.
Even in 8.4 and later? I would think that the anti-join that Tom
added in 8
On 1/7/11 1:29 AM, "??? " wrote:
>
>So my follow-up question on the subject is this:
>
>Are there any particular semantics for the "NOT IN" statement that cause
>the correlated query to execute for every row of the outter query, as
>opposed to the "NOT EXISTS" ?
=> select * from
Γιωργος Βαλκανας wrote:
Are there any particular semantics for the "NOT IN" statement that
cause the correlated query to execute for every row of the outter
query, as opposed to the "NOT EXISTS" ? Or are there any other
practical reasons, related to "IN / NOT IN", for this to be happening?
O
Thanks for the suggestion,
created_at is a timestamp without time zone type column. When I add +0 to
created at I get a cast error. I am able to get the query to use the
desired index when increasing or removing the limit, and I am still looking
for the reason why that is happening. Any advice
Euler Taveira de Oliveira wrote:
Em 07-01-2011 22:59, Greg Smith escreveu:
setrandom: invalid maximum number -2147467296
It is failing at atoi() circa pgbench.c:1036. But it just the first
one. There are some variables and constants that need to be converted
to int64 and some functions that m
