On 09/29/2017 01:10 PM, Tom Lane wrote: > Andrew Dunstan <andrew.duns...@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
