Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duRyM-000442-5r for pgsql-performance@arkaria.postgresql.org; Tue, 19 Sep 2017 23:30:34 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1duRyK-0001Pa-PQ for pgsql-performance@arkaria.postgresql.org; Tue, 19 Sep 2017 23:30:32 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1duRyJ-0001MS-Ux for pgsql-performance@postgresql.org; Tue, 19 Sep 2017 23:30:32 +0000 Received: from mail-qk0-x233.google.com ([2607:f8b0:400d:c09::233]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1duRyG-000488-R1 for pgsql-performance@postgresql.org; Tue, 19 Sep 2017 23:30:30 +0000 Received: by mail-qk0-x233.google.com with SMTP id u7so1168729qku.13 for ; Tue, 19 Sep 2017 16:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=O5KEpWmy9G6lnTUj3zP8mFCJZhOI3Rws7Xcw1RuMWyU=; b=NGb78X24aOEHkxwd5p2kUhzJUjKiYZz9REHhn1OIDv/O6F1CZtKqgLQc27z47qt2qX tOUruA6Jvp74Tnm04Z1MTMrJPOmrpC1OroDj5XNwsRPUccBVXdgqNqW5TlFjCflEEO70 pFRFWpZu+1C1Vgm2dSLbk+pMXF5ZdBbfIJmttauRUrwAFoHKmBW+Y2smWeaStHrhfh23 P959JwMPYcmLgfLqKVDHIoQglryHzsORPwECmBgVo3gMEhqPPWUgrh2KltDd2zRH3i+O 9igpK0Taajl9PM/2PMGtbd6w+ECPoqdtUPGAfpmchCVWSMMuwV2ZkJU/bhYRyg8vThtW HEAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O5KEpWmy9G6lnTUj3zP8mFCJZhOI3Rws7Xcw1RuMWyU=; b=T7eIp5fqf508T1/hjttHrsG59Eis1azzuUfC8NOw34ncKrXNGzAAjgowL6MwDSAUD5 H3k1gFqoayKh7Xqf5Qzya678KzWnb40ln266xnYO9MQ9fGv2RnkQ6O8GE5RbkOQ5XQF2 HUwTwfRSk+ndbTQ/iP67oHldLRLvocl1zmCcWNJLK9Br5qedaYztfFKOgynUQL+BT2Le FL8PWZ7hOnTm1VL5FnADhI+/yHMSfG5Y1o6zrC60MRz/LJpcjiwci42MYijdsYgTv2j4 gM85ODNvcanIqwq1m/OoKjkmhAO+HVNwfZefejBQe97t68K7uknVH6vf7ILRWaqTvr9h Dcqg== X-Gm-Message-State: AHPjjUhCuV8TFuOqqTE6j3WdFQMI2VKI1v+DYx4Y0VaEFGvi4Rv2Gnuw xoOoPDzVrmr3XppEO9XVAJq/MMAqzTau8vurw3rkaZk= X-Google-Smtp-Source: AOwi7QD6zqRq/trWkzX37yZwpbw9o4YnknnGGBuF7POKFnVYvZpd7pZ6bbWcfMpCcOp5okBN2dfKLfcSGv8W/fX/grA= X-Received: by 10.55.96.199 with SMTP id u190mr4455287qkb.197.1505863827709; Tue, 19 Sep 2017 16:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.84.35 with HTTP; Tue, 19 Sep 2017 16:30:27 -0700 (PDT) From: Jeff Janes Date: Tue, 19 Sep 2017 16:30:27 -0700 Message-ID: Subject: repeated subplan execution To: "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a114ce5c087e5b30559933e93" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a114ce5c087e5b30559933e93 Content-Type: text/plain; charset="UTF-8" I have a complicated query which runs the exact same subplan more than once. Here is a greatly simplified (and rather pointless) query to replicate the issue: select aid, sum_bid from (select aid, (select sum(bid) from pgbench_branches where bbalance between -10000-abalance and 1+abalance ) as sum_bid from pgbench_accounts where aid between 1 and 1000 group by aid ) asdfsadf where sum_bid >0; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------- Group (cost=0.44..375841.29 rows=931 width=12) (actual time=1.233..691.200 rows=679 loops=1) Group Key: pgbench_accounts.aid Filter: ((SubPlan 2) > 0) Rows Removed by Filter: 321 -> Index Scan using pgbench_accounts_pkey on pgbench_accounts (cost=0.44..634.32 rows=931 width=8) (actual time=0.040..1.783 rows=1000 loops=1) Index Cond: ((aid >= 1) AND (aid <= 1000)) SubPlan 2 -> Aggregate (cost=403.00..403.01 rows=1 width=8) (actual time=0.406..0.407 rows=1 loops=1000) -> Seq Scan on pgbench_branches pgbench_branches_1 (cost=0.00..403.00 rows=1 width=4) (actual time=0.392..0.402 rows=1 loops=1000) Filter: ((bbalance >= ('-10000'::integer - pgbench_accounts.abalance)) AND (bbalance <= (1 + pgbench_accounts.abalance))) Rows Removed by Filter: 199 SubPlan 1 -> Aggregate (cost=403.00..403.01 rows=1 width=8) (actual time=0.407..0.407 rows=1 loops=679) -> Seq Scan on pgbench_branches (cost=0.00..403.00 rows=1 width=4) (actual time=0.388..0.402 rows=1 loops=679) Filter: ((bbalance >= ('-10000'::integer - pgbench_accounts.abalance)) AND (bbalance <= (1 + pgbench_accounts.abalance))) Rows Removed by Filter: 199 Planning time: 0.534 ms Execution time: 691.784 ms https://explain.depesz.com/s/Xaib The subplan is not so fast that I wish it to be executed again or every row which passes the filter. I can prevent this dual execution using a CTE, but that creates other problems. Is there a way to get rid of it without resorting to that? Maybe also a question for bugs and/or hackers, is why should I need to do anything special to avoid dual execution? Cheers, Jeff --001a114ce5c087e5b30559933e93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have a complicated query which runs the exact same = subplan more than once.

Here is a greatly simplifi= ed (and rather pointless) query to replicate the issue:=C2=A0

select aid, sum_bid from
=C2=A0 =C2=A0 (select
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 aid,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (sel= ect sum(bid) from pgbench_branches
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 where bbalance between -10000-abalance and 1+abalance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ) as sum_bid
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 from pgbench_accounts
=C2=A0 =C2=A0 =C2=A0 =C2=A0 where ai= d between 1 and 1000
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group by aid
=C2=A0 =C2=A0 ) asdfsadf
where sum_bid >0;
<= div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0QUERY PLAN
------= ---------------------------------------------------------------------------= --------------------------------------------------------------------
<= div>=C2=A0Group =C2=A0(cost=3D0.44..375841.29 rows=3D931 width=3D12) (actua= l time=3D1.233..691.200 rows=3D679 loops=3D1)
=C2=A0 =C2=A0Group = Key: pgbench_accounts.aid
=C2=A0 =C2=A0Filter: ((SubPlan 2) > = 0)
=C2=A0 =C2=A0Rows Removed by Filter: 321
=C2=A0 =C2= =A0-> =C2=A0Index Scan using pgbench_accounts_pkey on pgbench_accounts = =C2=A0(cost=3D0.44..634.32 rows=3D931 width=3D8) (actual time=3D0.040..1.78= 3 rows=3D1000 loops=3D1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Index = Cond: ((aid >=3D 1) AND (aid <=3D 1000))
=C2=A0 =C2=A0SubPl= an 2
=C2=A0 =C2=A0 =C2=A0-> =C2=A0Aggregate =C2=A0(cost=3D403.= 00..403.01 rows=3D1 width=3D8) (actual time=3D0.406..0.407 rows=3D1 loops= =3D1000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-> =C2=A0Seq= Scan on pgbench_branches pgbench_branches_1 =C2=A0(cost=3D0.00..403.00 row= s=3D1 width=3D4) (actual time=3D0.392..0.402 rows=3D1 loops=3D1000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filter: ((= bbalance >=3D ('-10000'::integer - pgbench_accounts.abalance)) A= ND (bbalance <=3D (1 + pgbench_accounts.abalance)))
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rows Removed by Filter:= 199
=C2=A0 =C2=A0SubPlan 1
=C2=A0 =C2=A0 =C2=A0-> = =C2=A0Aggregate =C2=A0(cost=3D403.00..403.01 rows=3D1 width=3D8) (actual ti= me=3D0.407..0.407 rows=3D1 loops=3D679)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0-> =C2=A0Seq Scan on pgbench_branches =C2=A0(cost=3D0.0= 0..403.00 rows=3D1 width=3D4) (actual time=3D0.388..0.402 rows=3D1 loops=3D= 679)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Filter: ((bbalance >=3D ('-10000'::integer - pgbench_accounts= .abalance)) AND (bbalance <=3D (1 + pgbench_accounts.abalance)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Rows Remov= ed by Filter: 199
=C2=A0Planning time: 0.534 ms
=C2=A0E= xecution time: 691.784 ms




The subplan is not so fas= t that I wish it to be executed again or every row which passes the filter.= =C2=A0

I can prevent this dual execution using a = CTE, but that creates other problems.=C2=A0 Is there a way to get rid of it= without resorting to that?

Maybe also a question = for bugs and/or hackers, is why should I need to do anything special to avo= id dual execution?

Cheers,

Jeff --001a114ce5c087e5b30559933e93--