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 1pNEZb-0006T1-Sf for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 14:58: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 1pNEZa-00087Z-AU for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Feb 2023 14:58:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNEZa-00084Y-0r for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 14:58:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNEZX-0008P5-V1 for pgsql-hackers@lists.postgresql.org; Wed, 01 Feb 2023 14:58:53 +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 311EwnUc1368470; Wed, 1 Feb 2023 09:58:49 -0500 From: Tom Lane To: Tomas Vondra cc: Bruce Momjian , Hari krishna Maddileti , PostgreSQL Hackers Subject: Re: Support for dumping extended statistics In-reply-to: References: Comments: In-reply-to Tomas Vondra message dated "Wed, 01 Feb 2023 14:30:01 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1368468.1675263529.1@sss.pgh.pa.us> Date: Wed, 01 Feb 2023 09:58:49 -0500 Message-ID: <1368469.1675263529@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tomas Vondra writes: > On 1/7/23 03:39, Bruce Momjian wrote: >> There is certainly interest in allowing the optimizer statistics to be >> dumped and reloaded. This could be used by pg_restore and pg_upgrade. > Indeed, although I think it'd be better to deal with regular statistics > (which is what 99% of systems use). Furthermore, we should probably > think about differences between major versions - until now we could > change on-disk format of the statistics, because we have reset them. Yeah, it's extremely odd to be proposing dump/reload for extended stats when we don't yet have it for plain stats. And yes, the main stumbling block is that you need to have a plan for stats changing across versions, or even just environmental issues. For example, what if the target DB doesn't use the same collation as the source? That would affect string sorting and therefore at least partially invalidate histograms for text columns. I actually did some work on this, probably close to ten years ago now, and came up with some hacks that didn't pass community review. It'd be a good idea to dig up those old discussions if you want to re-open the topic. regards, tom lane