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 1mPmMJ-0004XP-4N for pgsql-performance@arkaria.postgresql.org; Mon, 13 Sep 2021 13:50:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mPmMI-0001Qd-2t for pgsql-performance@arkaria.postgresql.org; Mon, 13 Sep 2021 13:50:54 +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 1mPmMH-0001QT-GF for pgsql-performance@lists.postgresql.org; Mon, 13 Sep 2021 13:50:53 +0000 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mPmME-0003gO-LM for pgsql-performance@lists.postgresql.org; Mon, 13 Sep 2021 13:50:52 +0000 Received: by mail-ej1-x630.google.com with SMTP id e21so21168148ejz.12 for ; Mon, 13 Sep 2021 06:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=1KDN4JzPBFAKOhaTIW+0iA4Z+rZrq1xImt/+QSUsTOA=; b=dHyDabDfOWdaNb27zIgysWmdpV6JjqlLRxaqAfHftLe7NZu0Gmv2Tfdu/izlGzpRGv qlNOmJ975p1j8jERyo2L2I0yxzaolMwK6Ok56932AIL5KFWirhNvTSQAWn9UzllV87ej kkgXgXxwcfGSuYHPw8GJ9HhLS6hZt44tt1Uoj2Sx35iBp7wNbxX/PSw6xl5B6/mU5+7d IQijaptjPyzhsoVFAJHgFg4pjdLZ4ndODlVVdiISP+Zn3kcZwFuQjke+nj5am1YbGP73 2KmcHDFLuajWOY6WHK3ucX6YPHB7YmcADH5Lo+zZLEdJ6M4Xv7w3TBSpyvSn/YcYe1Qc 3NYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1KDN4JzPBFAKOhaTIW+0iA4Z+rZrq1xImt/+QSUsTOA=; b=e0lBO1VZ2AGwZ5/nIEU7F/CosRXzILibsqZO6GcHrG1bgcRGpJzTzRtU27ABnoSfEq djNXtTLkLWCxBajqwdO3KwQxSGEIJk5Uv4V83kV2ITawcRDrvcDywt2YTniy3mN2VZ+M 9Y/3tbmxCKplx7gNOPX8FLdPxgx4oO65t/G28+c2d0YIi8fJwO2exwHDN2e1kwW/h7sN a4OSp7BhK407YZV0eSQgqJECLRu+Q8LdsLdw76Ly3mIhOuLoN5qKupImzMD795pvQBpC 8cGQ+x8iN0415FRV8RwV3c3p1iB2vTDz2xC18UsCSqA3AhQDQ1fnxDknkDYWx/PHEASj jCzg== X-Gm-Message-State: AOAM530wyVQJ40IlJ36EWZSwrW5F3tqHsS2ZRKJHv25qnnx2J0TnMF9j ONtSQJxj7vh10LgdIG4ZriR5oEk5drqmxL1KuYSXqdxqjvs/BYPqdSdgSkcnudXo16+IscXrMbe 8NWAEDAgRt09j1FnCZju3gnZDvOciglHo4l2aMTGwO9idce41kqGQBY2j5tbry1P0Idbz/FJVp/ ZagclYpaNhb+Ze8W03w0aXD28wCySgriKu74lKrA3Boxmo2IBbRBG9lp2mBmlywGW0s7gNNiwqp rHll1etuXID2onEG2uAQ7uYfWgJAWFiRzZ3iQzlqq3D6A7XKPpUVlOVCjlIpChb X-Google-Smtp-Source: ABdhPJysJVK/RdOpkYc8wDyMpnUzvIhAfp1rIazK+xtzww56tUNWa48wFYBBAjv/2sQabsj4Lu+7ug== X-Received: by 2002:a17:906:4e8d:: with SMTP id v13mr12734455eju.436.1631541048786; Mon, 13 Sep 2021 06:50:48 -0700 (PDT) Received: from [10.137.0.19] (ip-86-49-241-1.net.upcbroadband.cz. [86.49.241.1]) by smtp.gmail.com with ESMTPSA id z6sm3400585ejj.13.2021.09.13.06.50.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Sep 2021 06:50:48 -0700 (PDT) Subject: Re: Postgres chooses slow query plan from time to time To: Kristjan Mustkivi , pgsql-performance@lists.postgresql.org References: From: Tomas Vondra Message-ID: <31c01752-c4d6-7751-9d25-b1fac8f3a7aa@enterprisedb.com> Date: Mon, 13 Sep 2021 15:50:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-CLOUD-SEC-AV-Info: enterprisedb,google_mail,monitor X-CLOUD-SEC-AV-Sent: true X-Gm-Spam: 0 X-Gm-Phishy: 0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 9/13/21 3:24 PM, Kristjan Mustkivi wrote: > Dear community, > > I have a query that most of the time gets executed in a few > milliseconds yet occasionally takes ~20+ seconds. The difference, as > far as I am able to tell, comes whether it uses the table Primary Key > (fast) or an additional index with smaller size. The table in question > is INSERT ONLY - no updates or deletes done there. > It'd be really useful to have explain analyze for the slow execution. My guess is there's a poor estimate, affecting some of the parameter values, and it probably resolves itself after autoanalyze run. I see you mentioned SET STATISTICS, so you tried increasing the statistics target for some of the columns? Have you tried lowering autovacuum_analyze_scale_factor to make autoanalyze more frequent? It's also possible most values are independent, but some values have a rather strong dependency, skewing the estimates. The MCV would help with that, but those are in PG12 :-( regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company