Hello Hackers,
I had some performance problems with a plpgsql function I developped,
because the function is very costly (it involves querying tables) and the
query optimiser assumed basically that it was an inexpensive function.
I found a workaround, but the problem may worth being adressed:
Instead of doing:
filter costly_function(attribute of table1)
on join (table1, table2)
It did:
join(filter costly_function(attribute of table1) on table1,
table2)
This was a very bad idea, because table1 is much larger than join(table1,
table2) as some other low cost filtering conditions are available.
Question:
- how to tell the optimiser about the cost of an individual function
(I think that very costly would be enough).
I haven't found a clue about the issue in the documentation.
Maybe an additional field would be added to pg_proc and or pg_operator
is needed?
Have a nice day,
--
Fabien Coelho - [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
