Heyho!
On Wednesday 07 July 2010 13.42:59 Martin Below wrote:
> I'm facing a strange problem where the optimizer does pick the wrong
> index.
What's not clear to me is why you want pg to chose a particular index. Are
you having performance issues? (The case you show is a table with 200k rows
-
Merlin Moncure 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 ot
On Thu, Jul 8, 2010 at 10:11 AM, Tom Lane wrote:
> Martin Below writes:
>> test=# select count(*) total, count(distinct client_id) ids,
>> count(distinct expires_on) dates from ps;
>> total | ids | dates
>> ++
>> 213645 | 123366 | 213549
>
> That says the expires_on
Martin Below writes:
> test=# select count(*) total, count(distinct client_id) ids,
> count(distinct expires_on) dates from ps;
> total | ids | dates
> ++
> 213645 | 123366 | 213549
That says the expires_on column is practically unique, which makes me
think the plann
Hello Merlin,
thanks for your help.
> can you supply the plans on the actual tables? the 'wrong' index
> might actually be the 'right' one if expires_on is of high cardinality
> (perhaps it's distributed badly and the table needs a stats tweak to
> make it correct).
test=# select count(*) total
Martin Below writes:
> Why is "idx_wrong" used (which only includes one of the fields
> queried) instead of idx_correct (which contains both fields)?
It's not immediately clear that that choice is "wrong". A two-column
index is bigger and hence more expensive to search than a one-column
index --
On Wed, Jul 7, 2010 at 7:42 AM, Martin Below
wrote:
> Hello,
>
> I'm facing a strange problem where the optimizer does pick the wrong index.
> Im using postgres 8.4, and my schema look like this:
>
> client_id | character varying(36) | not null
> key | character varying(16)
Hello,
I'm facing a strange problem where the optimizer does pick the wrong index.
Im using postgres 8.4, and my schema look like this:
client_id | character varying(36) | not null
key | character varying(16) | not null
expires_on | timestamp without time zone | not null
