Simon Riggs <simon@2ndQuadrant.com> writes:
> We can override table stats but not functions stats. I noticed that hole
> in the previous implementation, and rectified it with the intention of
> helping users with what I saw as a small, low risk patch that exactly
> followed existing code. It would seem I did that too quickly without
> realising that an objection would occur.
Well, you did it without much thought at all. I think this episode is a
perfect demonstration of why we ask for concrete use-cases for proposed
hooks. If you'd actually tried to write something that used the hook,
you'd surely have noticed that it wasn't being passed the information
that it would need to do anything useful, and you'd probably have
recognized the problem that there's no good way for a single hook
function to provide an extensible collection of function-specific
knowledge.
But the other point is that people aren't going to want to have to write
C-language hook functions in order to provide estimators for
user-defined functions. We need to think of something higher-level than
that. I think there was some discussion of generalizing the COST/ROWS
constants into SQL expressions using the function arguments, which the
planner could evaluate if it could reduce the arguments to constants.
I'm not sure if that would be adequate or even useful, but it seems more
likely to be helpful than a bare hook function.
regards, tom lane
