From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Martin Below <machtin(dot)below(at)googlemail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: optimizer choosing the wrong index |
Date: | 2010-07-08 18:53:15 |
Message-ID: | 29483.1278615195@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> I think so too, but suppose we wanted to force the other plan anyways:
> select * from ps where (client_id, expires_on) >=
> ('123', '24.11.2010'::timestamp) and (client_id, expires_on) < ('123',
> null) order by client_id, expires_on;
A simpler way to force use of the other index is
begin;
drop index wrong_index;
explain analyze my_query;
rollback;
> I'd be curious to see explain analyze (not explain) comparisons for
> the 'wrong' index vs above. I suspect the plan is 'correct' for
> *most* of the data, or you cherry picked (or unluckily drew) a bad
> value to get your 22 times speed difference.
Yeah, it would be interesting to see explain analyze output for both
cases, and for a few different values of the expires_on date if this
one is unlike the typical value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Susan Cassidy | 2010-07-08 18:58:51 | weird empty return from select problem; periodically get no data returned - could it be a network issue? |
Previous Message | Bryan Montgomery | 2010-07-08 18:50:18 | Re: GSS Authentication |