>>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes:
> Andrew Gierth <and...@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. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
