Skip site navigation (1) Skip section navigation (2)

Re: Performance problem in textanycat/anytextcat

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-29 20:43:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, May 17, 2010 at 9:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

This is still on the 9.0 open items list, but ISTM you fixed it with
two commits on May 27th.  Is that correct?

Robert Haas
The Enterprise Postgres Company

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-05-29 21:09:02
Subject: Re: PG 9.0 release timetable
Previous:From: Bruce MomjianDate: 2010-05-29 20:19:53
Subject: PG 9.0 release timetable

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group