On 09/29/2017 01:10 PM, Tom Lane wrote:
> Andrew Dunstan <andrew.dunstan@2ndquadrant.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
Nice.
>
> 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
>
>
Yeah, testing the worst case was the idea. This improvement in the
non-worst case is pretty good.
+1 for going ahead.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
