Re: Query planner/stored procedure cost

"Jason M. Felice" <jfelice@cronosys.com> writes:
> What am I looking at in doing the following:
> 1) Adding a mechanism to tell PostgreSQL how expensive a procedure is

Something like reverting to Postgres 4.2 :-(

There are still traces in the code of someone's PhD thesis concerning
where to invoke expensive functions.  But it's extremely dead code.
Bringing it back to life would involve substantial attention from a
wizard.

> 3) Changing the query planner to consider "bubbling up" the function to
>    an outer filter slot.

This is a bit tricky now, because there is a bunch of equality-deduction
logic that assumes that WHERE quals are applied as soon as possible.
You'd have to think about the costs of abandoning those optimizations vs
the costs of evaluating the expensive function too soon.  Right offhand
I see no principled way to make that choice, because in our bottom-up
planner it has to be made before you can possibly have an idea of the
full consequences.

> 4) Changing the planner to order expressions in a `Filter' slot by cost.

This we could do --- there's already a hack to push subselects past the
other clauses.  I've hesitated to do too much in that area, because the
user might know better than the planner which clauses to apply first.
But at least it's a pretty localized decision.
        regards, tom lane