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 1jW3FD-0000fT-Sb for pgsql-performance@arkaria.postgresql.org; Tue, 05 May 2020 19:28:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jW3FC-0007Y7-Mp for pgsql-performance@arkaria.postgresql.org; Tue, 05 May 2020 19:28:42 +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 1jW3FC-0007Xm-CG for pgsql-performance@lists.postgresql.org; Tue, 05 May 2020 19:28:42 +0000 Received: from mail-qk1-x735.google.com ([2607:f8b0:4864:20::735]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jW3F9-0001Pn-OZ for pgsql-performance@postgresql.org; Tue, 05 May 2020 19:28:41 +0000 Received: by mail-qk1-x735.google.com with SMTP id f83so3544898qke.13 for ; Tue, 05 May 2020 12:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jlkTCpxTP3FpLbpWYGYXUcbhn3bQDWF8tOhrhRFG7ZE=; b=eu5o0LmqFcU6Y3n3Dm2I4sY0ulDzsJaVNg8dHaEeKKWs1Xj9JeR5yeSF3Hs+2mNCLW R/QfrwRa4S2+upJ8dxEwJpDrZV6wYhsQ8el5Z+38is4wX8vt01AdesUPc2q3sFle5GEr qL7L1JszdHgAdPPaD96+XDdqc6MJXx+P4fCS28mcHJB4kgrmyrWW+/MiRi0n5sILePbP 9+Ksv9YKKd7Z3lwWQpKJbwhFF0vwg2cIU8Ta+i4Y404ew3o0vBHHvVOGpHvI+ayeXF+R gb0WqMdpjCaTWeMlZPNKtFs0LHZRkIWnz2cTOZjnFUsnIrGMYkkvyMkgeOf8+nB7225M oKLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jlkTCpxTP3FpLbpWYGYXUcbhn3bQDWF8tOhrhRFG7ZE=; b=aumviRs3p61lxzLp5lGpOLH0V9lyY8RSq1zoFsUO4N067bjIIt/liggdLPN/umHmaZ uJZSVWGoKQhPSlZj4ZRVUv1+OPDYKm5qlvdCRUQxvjF95EXMqvr5KqWRd2m+W/fJtKPP aJD3BpvNuM1tTjC9g711R/6NM+ZQhDRPJMhbYbIbPYRR54gZ1tv2EGv6tfi1TCMo+0iN 3WFeU1UpGeneYn5tw7n7HRcsCre3soVeVctVmOri63hXJvcbQ99ExMAck7DjZzfCLpju kRlkzOHF/IsT0D+cRDyb12P9mw35eMAYYDQ3fcbhHY6QDHwPOUpN3MWzwq7el95osgEZ nzTA== X-Gm-Message-State: AGi0PuaUAi/S/HIOba/GdmH+UeZhDoZaLZtId3gZuGFzgTx+9hU0bXyb s8nX+t+negD3zkfzeNTGxgkPCOVQAVA= X-Google-Smtp-Source: APiQypJlDWHLUdoH3pvEbLXRpIvtIU0IUtozxcOym3yxFnHJaHyGWqGBdHjIH8CLu5HU6UQLtT78bQ== X-Received: by 2002:a37:67c3:: with SMTP id b186mr5121699qkc.401.1588706918636; Tue, 05 May 2020 12:28:38 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id b10sm2498374qtj.30.2020.05.05.12.28.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 12:28:37 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 4E010800A79; Tue, 5 May 2020 14:28:36 -0500 (CDT) Date: Tue, 5 May 2020 14:28:36 -0500 From: Justin Pryzby To: Jamie Thompson Cc: pgsql-performance@postgresql.org Subject: Re: Please help! Query jumps from 1s -> 4m Message-ID: <20200505192836.GD28974@telsasoft.com> References: <20200503153825.GK28974@telsasoft.com> <20200504191201.GU28974@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200504191201.GU28974@telsasoft.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, May 04, 2020 at 02:12:01PM -0500, Justin Pryzby wrote: > On Mon, May 04, 2020 at 08:07:07PM +0100, Jamie Thompson wrote: > > Additionally, the execution plans for the 10th + following queries look > > fine, they have the same structure as if I run the query manually. It's not > > that the query plan switches, it seems as though the same query plan is > > just > 200X slower than usual. > > Are you able to reproduce the problem manually ? > > With/without PREPARE ? > https://www.postgresql.org/docs/current/sql-prepare.html Also, you should be able to check if that's the problem by doing either: plan_cache_mode = force_generic_plan; Or (I would think) DISCARD PLANS; https://www.postgresql.org/docs/12/runtime-config-query.html -- Justin