Re: Performance problem in textanycat/anytextcat

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, May 17, 2010 at 4:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Perhaps this is a backpatchable bug fix. Comments?

> I can't say whether this is safe enough to back-patch, but the way
> this is set up, don't we also need to fix some catalog entries and, if
> yes, isn't that problematic?

The only catalog entries at issue, AFAICT, are the textanycat/anytextcat
ones. I am not sure whether we should attempt to back-patch changes for
them, but this patch wouldn't make the situation in the back branches
worse. In particular, if we apply this patch but don't change the
catalog entries, then nothing would change at all about the problematic
cases, because the planner would decide it couldn't safely inline the
function. The only cases where inlining will happen is where the
expression's apparent volatility stays the same or decreases, so as far
as that issue is concerned this patch will never make CREATE INDEX
reject a case it would have accepted otherwise. The patch *will* make
CREATE INDEX reject cases with volatile default arguments hiding under
non-volatile functions, but that's got nothing to do with any built-in
functions; and that's the case I claim is clearly a bug fix.

regards, tom lane