Re: 8.3devel slower than 8.2 under read-only load - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.3devel slower than 8.2 under read-only load
Date
Msg-id 26304.1196044396@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.3devel slower than 8.2 under read-only load  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> But since your columns are varchar, which doesn't have any operators of its
>> own, we have to go through oper_select_candidate()

> I wonder whether at some point we shouldn't just eliminate this distinction
> entirely. Just make "text" and "varchar" the same type and spell it "text"
> when there's no typmod length restriction and "varchar(x)" when there is.

I've thought about that more than once, but I'm worried that it would
eliminate one of the few heavily-used cases we have for
binary-compatible operations, thereby making it even harder to find
performance issues for those situations.  In any case, it wouldn't do
anything to fix the basic problem that ambiguous-operator resolution is
expensive when there are lots of similarly-named operators.  We've
chipped away at that with various hacks over the years, but I don't
think it's ever occurred to us (or at least to me) before to try
short-circuiting the entire process through a lookaside cache.
We'd probably need to flush the cache on changes in pg_operator
or pg_cast, but neither of those change often ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: 8.3devel slower than 8.2 under read-only load
Next
From: Gregory Stark
Date:
Subject: Re: quote_literal(integer) does not exist