Re: Re: [COMMITTERS] pgsql: Add missing optimizer hooks for function cost and number of rows. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Add missing optimizer hooks for function cost and number of rows.
Date
Msg-id 6802.1272122224@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Add missing optimizer hooks for function cost and number of rows.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Re: [COMMITTERS] pgsql: Add missing optimizer hooks for function cost and number of rows.  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sat, Apr 24, 2010 at 3:31 AM, Simon Riggs <simon@2ndquadrant.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.

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.  (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.

Please revert.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Terry Brown
Date:
Subject: Re: psql: Add setting to make '+' on \d implicit
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: global temporary tables