Prev: pgsql: Add missing optimizer hooksfor function cost and number of rows.
Next: proposal - structured funcid and lineno as new fields in error message
From: Tom Lane on 24 Apr 2010 12:59 Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |