Re: inheritance, and plans - Mailing list pgsql-performance

From Andrew Gierth
Subject Re: inheritance, and plans
Date
Msg-id 87mycwpxg4.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: inheritance, and plans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 > Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
 >> Type-dependent selection of operators has already been done as
 >> part of parse analysis, no? And the domain -> base conversion is
 >> purely a relabelling, no? So what semantic change is possible as a
 >> result?

 Tom> Domain conversions are *not* simply relabellings.  It's possible
 Tom> now to have domain-specific functions/operators,

Right, but that's irrelevent to the planner in this case because the
resolution of precisely which operator is being called has _already
happened_ (in parse analysis), no?

 Tom> It's possible that there are specific cases where the UNION
 Tom> optimization checks could allow domains to be treated as their
 Tom> base types,

The domain -> base conversion is an important one (to anyone who uses
domains) because it happens implicitly in a wide range of contexts,
and so it's unsatisfactory for it to have major performance impacts
such as interfering with important optimizations.

 Tom> but blindly smashing both sides of the check to base is going to
 Tom> break more cases than it fixes.

The posted code was only looking up the base type for one side, not
both (though I don't know that code well enough to know whether it was
the correct side); the case of interest is when the subquery has the
domain type but the outer query is seeing the base type, _not_ the
reverse.

--
Andrew.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: inheritance, and plans
Next
From: Grzegorz Jaśkiewicz
Date:
Subject: Re: inheritance, and plans