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 1lZExd-0006w8-F3 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Apr 2021 15:40:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lZExc-0001Tq-5F for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Apr 2021 15:40:16 +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 1lZExb-0001Rv-UH for pgsql-hackers@lists.postgresql.org; Wed, 21 Apr 2021 15:40:15 +0000 Received: from mail-ot1-x329.google.com ([2607:f8b0:4864:20::329]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lZExW-00025Q-9U for pgsql-hackers@postgresql.org; Wed, 21 Apr 2021 15:40:14 +0000 Received: by mail-ot1-x329.google.com with SMTP id k14-20020a9d7dce0000b02901b866632f29so39317130otn.1 for ; Wed, 21 Apr 2021 08:40:10 -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=K27LZAoGJ7sJPnC34BQOaWTF/XI3F80yF14/TTnz0dQ=; b=AL6miGr3EqIjwxfUQa2Sn55IITHD3ZQnSGdPgBP9+MpBSfC6G/bYhRpso1pqFPm//N 0Qn6y5tttF16fHDKWja9ElXpInW4hiw6AJLSMHEt+wZ48j3L0yn6oOFQFXfn/n3RAlei QJx2x8GZkvuw4Qw89ECuz4WxLVTmVNgKC5DNi1HMXXEwevfra6S4GEjzkfmXCfEvqgXt EHiTok652cEdrzyVRTgFPh608JzfGrlHfP2ql7xrq2MT4p/U/Nydm7zwUAf1wMCSCNMI lyzN5LAGxa2mNiP+UY/YRTny2I8ePxPSixgKW4tsBBG9wlihMQJZYf/i/3rT/KnmAaLI UXXw== 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=K27LZAoGJ7sJPnC34BQOaWTF/XI3F80yF14/TTnz0dQ=; b=G2lVSRQJy98rw2rAgklpZnjoUBWR1MFtUr59fUSyfvA2PNpSL+Y12AHhQnjH8yQ2h+ MtBMksmpggw6pXizydxLt6S2PwamF//5SU28djNrV3BL0IhovljbeI3qq3QHKenST9dg VzAt4dhnhtsnAbaVj/yuA3D3Y3nYveSifsEBRZMvJ9bRDaRACj+ftnpAEs328AXav9Bf xDU8KHmJssNP3hd6j8cBSMmgIqKAgwz0KwRltBvSoi4C020a4muYfFNBeMV5M833iznb Wh6dauGrl7c6EqzMK4uEHweahokZZ2GwqZdSAlrIVfh9ZHYrDXIIEydPa7DVVKi5+yt+ dAYA== X-Gm-Message-State: AOAM533Vuik9u3xpZFZhibJr0js0v/9mV6wMiD+UvU3l87y57wpnluji 9KAUOOTFMlGCQSk9HW3/q/hXrA== X-Google-Smtp-Source: ABdhPJwdCaztIZu+XIFdVCRViw8bTIWT3RLc+Vl7lgporsMpbWHgUOYEJmI/aZ8tbdVUg/jHCib/XQ== X-Received: by 2002:a9d:7453:: with SMTP id p19mr23147594otk.271.1619019609446; Wed, 21 Apr 2021 08:40:09 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id p15sm600159otl.23.2021.04.21.08.40.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Apr 2021 08:40:09 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id E29B48006F0; Wed, 21 Apr 2021 10:40:07 -0500 (CDT) Date: Wed, 21 Apr 2021 10:40:07 -0500 From: Justin Pryzby To: Fujii Masao Cc: Pavel Stehule , Peter Geoghegan , Julien Rouhaud , "Tharakan, Robins" , pgsql-hackers@postgresql.org Subject: Re: track_planning causing performance regression Message-ID: <20210421154007.GU7256@telsasoft.com> References: <646e5cae-5e8b-feaa-43dc-014bf355bf08@oss.nttdata.com> <20210418233615.GB7256@telsasoft.com> <20210419145545.GF7256@telsasoft.com> <20210421145338.GT7256@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Apr 22, 2021 at 12:13:17AM +0900, Fujii Masao wrote: > On 2021/04/21 23:53, Justin Pryzby wrote: > > Or: > > > > Enabling this parameter may incur a noticeable performance penalty, > > especially similar queries are executed by many concurrent connections > > and compete to update a small number of pg_stat_statements entries. > > I prefer this. But what about using "identical" instead of "similar" > because pg_stat_statements docs already uses "identical" in some places? I also missed "when", again... > > Enabling this parameter may incur a noticeable performance penalty, > > especially when queries with identical structure are executed by many concurrent connections > > which compete to update a small number of pg_stat_statements entries.