Re: why provide cross type arithmetic operators

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "ykhuang" <hyk(at)ruc(dot)edu(dot)cn>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: why provide cross type arithmetic operators
Date: 2008-01-22 17:42:58
Message-ID: 4006.1201023778@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "ykhuang" <hyk(at)ruc(dot)edu(dot)cn> writes:
>> there are many cross type arithmetic operators, like int2 + int4, int8 +
>> int4, I think these can be deleted. Here are the reasons, after deleted,
>> int2 + int4 will choose the operator int4 + int4, int8 + int4 choose int8 +
>> int8, Is that ok? Thanks.

> Then the system wouldn't be able to use indexes as flexibly. For example if
> you have an index on an int2 column and perform a query with a restriction
> like "int2col = 1" the system wouldn't find a matching =(int2,int4) operator
> and would instead have to do a sequential scan casting the int2 column to an
> int4 when checking each row.

This is a reason not to remove "redundant" indexable operators, but the
argument doesn't have a lot of force for non-indexable ones.

I looked into this, and the reason we fail to resolve int2 + int8 is
that after the "prefer more exact matches" test (the first heuristic in
func_select_candidate) we are down to int8 + int8 and int4 + int8,
and none of the remaining heuristics can prefer one over the other.
On the other hand, we resolve int2 < int8 just fine because there's an
exact match.

So it seems that the problem with cross-type operators is not so much
having them as having incomplete sets of them. We could fix this case
either by adding int2 + int8 or by removing int4 + int8, and simplicity
would seem to argue for the latter.

A different approach would be to add a heuristic preferring
same-input-type operators over others. (We currently apply that idea
only when one of the inputs is "unknown" type, which is why
'1' + int8'1' works.) It's a bit scary to wonder what cases that might
break, though.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2008-01-22 17:56:14 Re: bad message or bad privilege check in foreign key constraint
Previous Message Tom Lane 2008-01-22 16:36:35 Re: BUG #3881: lo_open leaks memory