Re: inheritance, and plans
От | Andrew Gierth |
---|---|
Тема | Re: inheritance, and plans |
Дата | |
Msg-id | 87mycwpxg4.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: inheritance, and plans (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: