Re: Should planner fold "stable" functions for estimation purposes?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rod Taylor <rbt(at)rbt(dot)ca>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Should planner fold "stable" functions for estimation purposes?
Date: 2004-03-13 01:04:00
Message-ID: 13889.1079139840@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Rod Taylor <rbt(at)rbt(dot)ca> writes:
>> It would not be correct to reduce the righthand side to a constant in
>> advance of execution, of course, but is it reasonable to compute its
>> current value solely for purposes of comparison to column statistics?

> So this means it would be double evaluated? A flag will be required to
> prevent this for functions that do more than just return a value or have
> a high cost in execution.

Functions with side-effects had better be marked volatile anyway, so I'm
not worried about that case. As for the expense argument, keep in mind
that the one extra evaluation in the planner is likely to save you an
awful lot of evaluations at runtime, if it convinces the planner to use
an indexscan and not a seqscan. We are after all talking about
functions appearing in WHERE, and I wouldn't think that people can
reasonably expect those to get evaluated just once.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2004-03-13 01:38:37 rapid degradation after postmaster restart
Previous Message Tom Lane 2004-03-12 23:36:10 Should planner fold "stable" functions for estimation purposes?