| 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: | Whole Thread | Raw Message | 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 |