From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Vyacheslav Kalinin" <vka(at)mgcp(dot)com> |
Cc: | PGSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Subplan and index usage |
Date: | 2008-03-13 20:15:03 |
Message-ID: | 302.1205439303@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Vyacheslav Kalinin" <vka(at)mgcp(dot)com> writes:
> [ poor estimation for ]
> select *
> from cities
> where ( ficity_id in (
> select ficity_id from cities_name_words
> where fsword like 'novgorod%'
> union
> select ficity_id from cities_name_ru_words
> where fsword like 'novgorod%'
> )
> or lower(fsname) like 'novgorod%'
> or lower(fsname_ru) like 'novgorod%'
> )
When you have an IN at the top level of WHERE, it's flattened into a
kind of JOIN, and there's reasonably decent estimation of the
selectivity. Unfortunately, when it's down inside an OR-clause like
this, all those smarts go out the window and it's just treated as a
generic subplan condition, with 0.5 estimated selectivity IIRC.
Improving that would be nice but it's not high on anyone's to-do list.
You might get better results if you combine three separate queries
with UNION.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Paul | 2008-03-13 20:26:01 | Re: Segmentation fault (core dumped) loading data on 8.3 upgrade: undefined symbol 'pg_valid_server_encoding_id', lazy binding failed! |
Previous Message | brian | 2008-03-13 20:02:49 | Re: Dump format for long term archiving. |