Re: 8.3devel slower than 8.2 under read-only load

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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