Mark Dilger wrote:
I've been thinking about this more, and now I don't see why this is an
issue. When the planner estimates how many rows will be returned from a
subquery that is being used within a join, it can't know which
"parameters" to use either. (Parameters being whatever conditions the
subquery will pivot upon which are the result of some other part of the
execution of the full query.) So it seems to me that function S() is at
no more of a disadvantage than the planner.
If I defined a function S(a integer, b integer) which provides an
estimate for the function F(a integer, b integer), then S(null, null)
could be called when the planner can't know what a and b are. S could
then still make use of the table statistics to provide some sort of
estimate. Of course, this would mean that functions S() cannot be
defined strict.
Ok, null probably isn't a good value. F(null, null) could be the call being
made, so S(null, null) would mean "F is being passed nulls" rather than "We
don't know what F's arguments are yet". The returned estimate might be quite
different for these two cases. You could have:
F(a integer, b integer)
S(a integer, a_is_known boolean, b integer, b_is_known boolean)
But I'm not fond of the verbosity of doubling the argument list. Since some
arguments might be known while others still are not, I don't think a single
boolean argument all_arguments_are_known is sufficient.
---------------------------(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
