Hi,
On Tuesday 31 January 2006 18:59, you wrote:
> Shouldn't the query planner be able to do the right thing without the
> index? Where does the magic 'rows=459' come from?
ok - I've spend some time reading the postgres sources now. qesel() is using
a selectivity of DEFAULT_EQ_SEL (0.005) for all expressions with functions.
Since our query has three such equals AND'ed this gives a selectivity of
0.000000125 instead of 0.9. That's causing postgres to create a query plan
which runs aprox. 8 hours instead of less then a second.
I've now created a combined expression index for my case so the query planner
can check the selectivity. This is a huge overkill and there is a lot of
space for improvements..
As a last resort for such cases it would be good to be able to hardcode
selectivities in the SQL statements. Something like:
SELECT ...
FROM ...
WHERE con.ccu_objid IN (...)
AND cel.isActiv = 'Y'
AND ( upper(coalesce(dev.isActiv,'Y')) = 'Y'
AND upper(coalesce(dev.IsCommittedSP,'Y')) = 'Y'
AND upper(coalesce(dev.IsCommittedCust,'Y')) = 'Y'
) WITH SELECTIVITY 0.9
AND loc.shortName = '5195'
However, it would be great to have get_restriction_variable() and
get_attstatsslot() extended so they can pass the most common values
from the statistics cache thru expressions, as described in my earlier
mail.
yours,
- clifford
--
: Clifford Wolf Tel +43-1-8178292-00 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
