Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kaQ8x-0002WM-F7 for pgsql-performance@arkaria.postgresql.org; Wed, 04 Nov 2020 21:16:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kaQ8v-0001k1-Be for pgsql-performance@arkaria.postgresql.org; Wed, 04 Nov 2020 21:16:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kaQ8v-0001ju-4A for pgsql-performance@lists.postgresql.org; Wed, 04 Nov 2020 21:16:33 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kaQ8s-00036T-Uq for pgsql-performance@lists.postgresql.org; Wed, 04 Nov 2020 21:16:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0A4LGThY1322418; Wed, 4 Nov 2020 16:16:29 -0500 From: Tom Lane To: Eric Raskin cc: Michael Lewis , Pgsql Performance Subject: Re: Adding nextval() to a select caused hang/very slow execution In-reply-to: References: <1234726.1604513058@sss.pgh.pa.us> <1237035.1604516511@sss.pgh.pa.us> Comments: In-reply-to Eric Raskin message dated "Wed, 04 Nov 2020 15:39:41 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1322416.1604524589.1@sss.pgh.pa.us> Date: Wed, 04 Nov 2020 16:16:29 -0500 Message-ID: <1322417.1604524589@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Eric Raskin writes: > So, things get even weirder. When I execute each individual select > statement I am generating from a psql prompt, they all finish very > quickly. > If I execute them inside a pl/pgsql block, the second one hangs. > Is there something about execution inside a pl/pgsql block that is > different from the psql command line? Generic vs specific plan, perhaps? Are you passing any parameter values in from plpgql variables? IIRC, you could force the matter by using EXECUTE, though it's somewhat more notationally tedious. In late-model PG versions, plan_cache_mode could help you too. regards, tom lane