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 1pNXJC-0005i3-Ug for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 10:59:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNXJA-0003B0-1i for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 10:59:12 +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 1pNXJ8-0003Ac-O9 for pgsql-hackers@lists.postgresql.org; Thu, 02 Feb 2023 10:59:11 +0000 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNXJ4-0006Cm-7k for pgsql-hackers@lists.postgresql.org; Thu, 02 Feb 2023 10:59:09 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 98F96320098B; Thu, 2 Feb 2023 05:59:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 02 Feb 2023 05:59:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1675335543; x=1675421943; bh=M QhKjl+pYbUxOAB39zE+sZTkz1HkXoVdtwmDcOk3PoE=; b=czrbc6z6o1+YjDjB9 wcKkTTe3AsJi8C18NcHTEry51SvQY6RBYt8IB8TcGpLCcyPM2+SP7GFemdAafw9a Ev9j2+Sa5Sx3U7lPlYJ6nBh43woA60ZGjcBU8+Br6zqBGpuAeK4eBYHTDCPg3Qn/ xjamCbjuyhigZdQ5NpuH2WmRbeOd4sn5N0HN3RC5OX/fn7bkABkKrrVmv84jTKYW sQbH+2yfJVT/ABca2AtRH2fnkNGAA0o7O/VP9GnW46uCWnd3Z1udSGQT16k+sZhr IPAgbif/SOGFZDvd3TTf2eaAeZoN+tCUQSOWc3sr276gxH6Ee96ILvogvgVYYQL7 V4qvg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Feb 2023 05:59:02 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id CD88F9D; Thu, 2 Feb 2023 11:58:59 +0100 (CET) Date: Thu, 2 Feb 2023 11:58:59 +0100 From: Alvaro Herrera To: Robert Haas Cc: Tom Lane , pgsql-hackers@lists.postgresql.org, Andrew Subject: Re: pg_dump versus hash partitioning Message-ID: <20230202105859.f6wp77s2j3qsoyvz@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Feb-01, Robert Haas wrote: > I think you can construct plausible cases where it's not just > academic. For instance, suppose I intend to use some kind of logical > replication system, not necessarily the one built into PostgreSQL, to > replicate data between two systems. Before engaging that system, I > need to make the initial database contents match. The system is > oblivious to partitioning, and just replicates each table to a table > with a matching name. This only works if that other system's hashing behavior is identical to Postgres' for hashing that particular enum; there's no other way that you could make the tables match exactly in the way you propose. What this tells me is that it's not really reasonable for users to expect that this situation would actually work. It is totally reasonable for range and list, but not for hash. If the idea of --load-via-partition-root=auto is going to be the fix for this problem, then it has to consider that hash partitioning might be in a level below the topmost one. For example, create type colors as enum ('blue', 'red', 'green'); create table topmost (prim int, col colors, a int) partition by range (prim); create table parent partition of topmost for values from (0) to (1000) partition by hash (col); create table child1 partition of parent for values with (modulus 3, remainder 0); create table child2 partition of parent for values with (modulus 3, remainder 1); create table child3 partition of parent for values with (modulus 3, remainder 2); If you dump this with --load-via-partition-root, for child1 it'll give you this: -- -- Data for Name: child1; Type: TABLE DATA; Schema: public; Owner: alvherre -- COPY public.topmost (prim, col, a) FROM stdin; \. which is what we want; so for --load-via-partition-root=auto (or whatever), we need to ensure that we detect hash partitioning all the way down from the topmost to the leaves. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)