From: | Ernest E Vogelsinger <ernest(at)vogelsinger(dot)at> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Query planner question |
Date: | 2003-06-12 23:55:42 |
Message-ID: | 5.1.1.6.2.20030613015151.03b21068@mail.vogelsinger.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 23:56 12.06.2003, Stephan Szabo said:
--------------------[snip]--------------------
>I think that it doesn't entirely know that owid=1, sort by dcid, dsid,
>drid can be handled by that index. I think it's possible that if you
>added owid to the select list it might use id_dowid instead. I think this
>is similar to the issues with order by, conditions and index choice, which
>you may find useful information in the archives about)
Nope, still uses the wrong index, but as I said to Dimitry that's my least
problem ;-)
>> 2) Why is NO index used for the second query, the only difference being in
>> the constraint value (owid is set vs. owid is null)?
>
>IS NULL is not considered an indexable condition currently (there are past
>discussions and hackarounds in the archives)
Hmm - I'm not into hackarounds on a production server, really. I'll rather
modify the approach the application takes.
>> 3) Why does it use id_dictid for the second query when forced to, and not
>> id_owid or id_dowid?
>
>As for #2, it doesn't think it can use an index with owid in the front.
Makes perfectly sense since nulls can't be indexed *sigh*
Anyone know why this decision has been taken?
Thanks for your insight, guys :)
--
>O Ernest E. Vogelsinger
(\) ICQ #13394035
^ http://www.vogelsinger.at/
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Tkach | 2003-06-13 00:12:30 | Re: Query planner question |
Previous Message | Ernest E Vogelsinger | 2003-06-12 23:51:46 | Re: Query planner question |