Re: Arrays of domains

Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On 09/28/2017 05:44 PM, Tom Lane wrote:
>> Assuming that that's going to happen for v11, I'm inclined to leave the
>> optimization problem until the dust settles around CaseTestExpr.
>> Does anyone feel that this can't be committed before that's addressed?

> I'm Ok with it as long as we don't forget to revisit this.

I decided to go ahead and build a quick optimization for this case,
as per the attached patch that applies on top of what we previously
discussed. It brings us back to almost par with HEAD:

HEAD Patch + 04.patch

Q1 5453.235 ms 5440.876 ms 5407.965 ms
Q2 9340.670 ms 10191.194 ms 9407.093 ms
Q3 19078.457 ms 18967.279 ms 19050.392 ms
Q4 48196.338 ms 58547.531 ms 48696.809 ms

Unless Andres feels this is too ugly to live, I'm inclined to commit
the patch with this addition. If we don't get around to revisiting
CaseTestExpr, I think this is OK, and if we do, this will make sure
that we consider this case in the revisit.

It's probably also worth pointing out that this test case is intentionally
chosen to be about the worst possible case for the patch. A less-trivial
coercion function would make the overhead proportionally less meaningful.
There's also the point that the old code sometimes applies two layers of
array coercion rather than one. As an example, coercing int4[] to
varchar(10)[] will do that. If I replace "x::int8[]" with
"x::varchar(10)[]" in Q2 and Q4 in this test, I get

HEAD Patch (+04)

Q2 46929.728 ms 20646.003 ms
Q4 386200.286 ms 155917.572 ms

regards, tom lane