Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1duypD-0001jc-Qg for pgsql-performance@arkaria.postgresql.org; Thu, 21 Sep 2017 10:35:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1duypD-0001Wu-76 for pgsql-performance@arkaria.postgresql.org; Thu, 21 Sep 2017 10:35:19 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1duypC-0001Wa-I4 for pgsql-performance@postgresql.org; Thu, 21 Sep 2017 10:35:18 +0000 Received: from mail-it0-x235.google.com ([2607:f8b0:4001:c0b::235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1duypA-00017c-J6 for pgsql-performance@postgresql.org; Thu, 21 Sep 2017 10:35:18 +0000 Received: by mail-it0-x235.google.com with SMTP id c195so108557itb.1 for ; Thu, 21 Sep 2017 03:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BDvUAUebBmxImTrA0gXCnk6jPjvJntKdjBKTYrgRMVI=; b=GlJBuv0UUCjBscaEz/zjcV+9FngThraLS/7GQltV/t1MPXSEYj+J997zqbsI2sDSz1 HeyrphMwSOIOg0elIguyxLl/4o8DRcFNoykgJG1RN3CNWjJrbRRATojO/5XN1c7+Bh5C vRocPpjZjiqBN1TU5LwVWEwudbaqJQF4PgBySnfCsRpFa53pRqMMzNbfjVHw3gkzitMn vkzpwVfo4Sz/nW7dfaAwDGuyImqrmpg8sNy4zydepc/yZ9Z3U/mzoNWFxaU19U7IVb0P Edua8rw0gIrO75nxA1E9ruQUHu5M84Kt3h89SVVGl7BNpb2Obg0OPW2lQLnPst6D6pLW Cyag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BDvUAUebBmxImTrA0gXCnk6jPjvJntKdjBKTYrgRMVI=; b=kkZEHLvEqna+tuZ8ChThqoKKViE+LzYpPKbpkzEodnMIRwc4+8f6qzxrcFa01oRpRi dbGEVM266RUq0mf+GGHocXyeoW/pZiBDPgQWoX8skiL54qMoRlaXMHlWrK1wOc4DMXQ/ /tKrYe6qNfnScjx5X1nklFIVJoJRg56g8T55eCDoCv7nDH1OAuvkgg7TJSohLnFqVzYN j1vbu6E2TEZgsAN46G/JDqxsAr5YxiBpwj9qeGllWdTE49WJGh5nU99ozYnXDiYAHDRY BbSZ0dubK6hLQxsBRIRX4JlD+b8lyfy3VGWTmbxOB7wLT90EXz4WP/QRmXXuFMJ6l5fB ceeA== X-Gm-Message-State: AHPjjUikJAE5N85jyzfQt9fNNKOnpqn2KnmicnCnp3olE15Rk83MHabO FlX9W5iaqQZxE32devMJenzO4RB1I4kx+IPPYmU= X-Google-Smtp-Source: AOwi7QAsgb1011IyuVMfx9aQqu2zXdvqOc/rbTXqgi7EF+F0IcfjprmDdRTLPBTT+EnZT9EJvVrCx42rTBOG7pPN+1E= X-Received: by 10.36.16.130 with SMTP id 124mr754032ity.105.1505990114433; Thu, 21 Sep 2017 03:35:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.43.81 with HTTP; Thu, 21 Sep 2017 03:35:13 -0700 (PDT) In-Reply-To: References: From: monika yadav Date: Thu, 21 Sep 2017 16:05:13 +0530 Message-ID: Subject: Re: repeated subplan execution To: Jeff Janes Cc: "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a1140492cce61060559b0a533" 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 --001a1140492cce61060559b0a533 Content-Type: text/plain; charset="UTF-8" Hi Jeff, Thanks for the update and clarification. I will look to see a better alternative to resolve this twice execution of same plan. On Wed, Sep 20, 2017 at 10:16 PM, Jeff Janes wrote: > On Tue, Sep 19, 2017 at 7:31 PM, monika yadav > wrote: > >> Hi All, >> >> I didn't understand why same sub plan for the sub query executed two >> times? As per the query it should have been executed only once. >> >> Can someone please explain this behaviour of query execution ? >> > > > The sum_bid at the end of the query is an alias for the entire subselect, > so it not entirely surprising that it gets interpolated twice. it is just > kind of unfortunate from a performance perspective. > > The query I originally gave is equivalent to this query: > > > 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 > having (select sum(bid) from pgbench_branches where bbalance > between -10000-abalance and 1+abalance ) >0; > > > In my originally query I just wrapped the whole thing in another select, > so that I could use the alias rather than having to mechanically repeat the > entire subquery again in the HAVING section. They give identical plans. > > Cheers, > > Jeff > --001a1140492cce61060559b0a533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeff,

Thanks for the updat= e and clarification. I will look to see a better alternative to resolve thi= s twice execution of same plan.

On Wed, Sep 20, 2017 at 10:16 PM, Jeff Janes <= jeff.janes@gmail.com> wrote:
On Tue, Sep 19, 2017 at 7:31 PM, monika yadav <mon= ika.1234yadav@gmail.com> wrote:
Hi All,

I didn't understand why same sub plan fo= r the sub query executed two times? As per the query it should have been ex= ecuted only once.

Can so= meone please explain this behaviour of query execution ?=C2=A0
<= /blockquote>


The sum_bid at the en= d of the query is an alias for the entire subselect, so it not entirely sur= prising that it gets interpolated twice. it is just kind of unfortunate fro= m a performance perspective.

The query I originall= y gave is equivalent to this query:


=C2=A0select
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a= id,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (select sum(bid) from pgbench_bra= nches
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 where bbalance be= tween -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 aid between 1 and 1000
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 group by aid=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 having (select sum(bid) from pgbench_branches where bbala= nce between -10000-abalance and 1+abalance ) >0;


In my originally query I just wrapped the whole thin= g in another select, so that I could use the alias rather than having to me= chanically repeat the entire subquery again in the HAVING section.=C2=A0 Th= ey give identical plans.

Cheers,

Jeff

--001a1140492cce61060559b0a533--