Re: [HACKERS] Re: pgsql: Add missing optimizer hooks for function cost and number of rows.

On Sat, 2010-04-24 at 11:17 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Sat, Apr 24, 2010 at 3:31 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >> Existing hooks were not fully complete in their coverage. That has
> >> happened before, and we have discussed that before on hackers, so I took
> >> care not to deviate from that implementation. This is a very low impact
> >> change, isn't in a new area and similar optimizer related changes were
> >> made recently, so I saw little to object to in this particular change.
> >> No such hooks are documented, even ones with strong use cases.
>
> > The point isn't whether the existing hooks are complete or not. The
> > point is that we shouldn't be making undiscussed changes EVER, and
> > particularly not a week before beta.
>
> I have a problem with not only the process (or lack of it) but the
> substance of the patch. I don't believe that a system-wide hook point
> has any great use for improving function estimation. You need function-
> specific knowledge, and this is just not a useful way to package it.

I've revoked it.

> When we put in the COST/ROWS options for functions, it was generally
> agreed that the way forward would be to generalize those, eg by allowing
> per-function estimator functions to be called instead of just inserting
> constants.

I completely agree that the above is the best way forwards.

> (And I think the main reason we didn't just do that
> immediately was that we wanted a feature that could be used without
> doing C-level programming.) This patch doesn't do that, nor even lay
> any useful groundwork for doing it. It would be impossible for instance
> for this hook function to lay its hands on the arguments to the function
> to be estimated, which certainly begs the question as to how it's going
> to deliver any estimate more useful than the constant value.

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.

For the record, it's possible to use the main optimizer hooks to get the
same result, so I'm in no way personally blocked by this. I think that's
harder, so others may not find it as easy. This may actually help obtain
funding to implement the full approach, maybe.

--
Simon Riggs www.2ndQuadrant.com