[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Arrays of domains
From:       Andrew Dunstan <andrew.dunstan () 2ndquadrant ! com>
Date:       2017-09-29 20:17:22
Message-ID: db18e99b-3f5a-066c-d97c-2ecd3352622d () 2ndQuadrant ! com
[Download RAW message or body]



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
[prev in list] [next in list] [prev in thread] [next in thread]