Re: Performance problem in textanycat/anytextcat

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance problem in textanycat/anytextcat
Date: 2010-05-18 01:23:30
Message-ID: 27401.1274145810@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-05-18 01:37:27 Re: Performance problem in textanycat/anytextcat
Previous Message Robert Haas 2010-05-18 01:21:41 Re: GUCs that need restart