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 1pNO0U-00013e-Ai for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 01:03:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pNO0T-0003qx-7g for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Feb 2023 01:03:17 +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 1pNO0S-0003pX-To for pgsql-hackers@lists.postgresql.org; Thu, 02 Feb 2023 01:03:16 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNO0Q-0000ku-BT for pgsql-hackers@lists.postgresql.org; Thu, 02 Feb 2023 01:03:15 +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 31213ACo1440374; Wed, 1 Feb 2023 20:03:10 -0500 From: Tom Lane To: David Rowley cc: Peter Geoghegan , Robert Haas , pgsql-hackers@lists.postgresql.org, Andrew Subject: Re: pg_dump versus hash partitioning In-reply-to: References: <1376149.1675268279@sss.pgh.pa.us> <1412538.1675283692@sss.pgh.pa.us> <1425446.1675291093@sss.pgh.pa.us> Comments: In-reply-to David Rowley message dated "Thu, 02 Feb 2023 13:15:28 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1440372.1675299790.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 01 Feb 2023 20:03:10 -0500 Message-ID: <1440373.1675299790@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk David Rowley writes: > Digging into the history a bit, I found [2] and particularly [3] that > seem to indicate this option was thought about due to concerns about > hash functions not returning consistent results on different > architectures. I suspect it might have been defaulted to load into the > leaf partitions for performance reasons, however. I mean, why else > would you? > [3] https://www.postgresql.org/message-id/CA%2BTgmoZFn7TJ7QBsFatnuEE%3DG= YGdZSNXqr9489n5JBsdy5rFfA%40mail.gmail.com Hah ... so we went over almost exactly this same ground in 2017. The consensus at that point seemed to be that actual problems would be rare enough that we'd not need to impose the overhead of --load-via-partition-root by default. Now, AFAICS that was based on exactly zero hard evidence, as to either the frequency of actual problems or the cost of --load-via-partition-root. Our optimism about the former seems to have been mostly borne out, given the lack of complaints since then; but I still think our pessimism about the latter is on shaky grounds. Anyway, after re-reading the old thread I wonder if my first instinct (force --load-via-partition-root for enum hash cases only) was the best compromise after all. I'm not sure how painful it is to get pg_dump to detect such cases, but it's probably possible. regards, tom lane