Re: New thoughts about indexing cross-type comparisons - Mailing list pgsql-hackers

From Dennis Bjorklund
Subject Re: New thoughts about indexing cross-type comparisons
Date
Msg-id Pine.LNX.4.44.0309172011430.20470-100000@zigo.dhs.org
Whole thread Raw
In response to Re: New thoughts about indexing cross-type comparisons  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New thoughts about indexing cross-type comparisons
List pgsql-hackers
On Wed, 17 Sep 2003, Tom Lane wrote:

> Another thing to keep in mind is that it's not always the case that
> assigning the right type to a literal constant would solve the problem.
> We have the same issues with variables; for example, a join with
> "WHERE a.int8col = b.int4col" may fail to take advantage of available
> indexes.

Sure, which is why subtyping is needed to insert the correct coercions
(relations like int4 < int8 and such). Generating all constraints and then
have a planner phase/inference phase in the end that makes the chioces. By
not forcing anything too early you give the inference/planner the
possibility to make good choices (which might depend on what indexes are
available and so on).

> Something else that's been troubling me about the issue is that the most
> efficient operator to use is really context-dependent.  In the example
> of "WHERE a.int8col = b.int4col", we basically have two possible
> choices; use a cross-type operator (int8 = int4), or introduce a
> coercion, so that the clause becomes "WHERE a.int8col = b.int4col::int8"
> using an int8 = int8 operator.  The latter is a win when considering
> indexscans on the int8 column, and also a win for hash joins (cross-type
> operators in general aren't hashable).  *But* the former is a win for
> merge joins, and particularly for implied equality deduction.

Yes, by not making the decission directly but just setting constrants,
then you in the end have a set of possible solutions. And then the planner
have to choose among those.

> If we force the coercion-based representation to be used then the
> planner will be able to deduce that a.int8col and b.int4col::int8 are
> equal, but it would have to make a leap of faith to relate that
> knowledge to the bare b.int4col column.  This would eg. prevent the use
> of a mergejoin with use of an index on the int4 column.

If I understand what you say correctly, then yes. If you have an inference
phase before the planner phase that decides to insert a coercion from int4
to int8 then you have made a decission that forces you to use one plan
over another. And that should be made by the planner and not the type
inference.

> So I'm beginning to think that avoiding cross-type operators is not the
> right route to a solution anyway.  It may be better to leave the parser
> alone and teach the planner how to switch to the alternate
> representation when and where appropriate.

Yes, and the planner needs information about what alternative
representations there are (which is the same as letting the planner insert
coercions and selecting what == operator to use, or are you thinking of
something else).

Another problem is of course if one let the planner do too much work and 
have to many possible plans to choose from, it has to be fast.

-- 
/Dennis



pgsql-hackers by date:

Previous
From: "chakkara rangarajan"
Date:
Subject: change of table name - any help
Next
From: Tom Lane
Date:
Subject: Re: New thoughts about indexing cross-type comparisons