Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzjCb-006GIO-9M for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2024 20:26:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rzjCY-00HLcA-Na for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Apr 2024 20:26:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rzjCY-00HLbu-BX for pgsql-hackers@lists.postgresql.org; Wed, 24 Apr 2024 20:26:46 +0000 Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzjCV-004TCK-NP for pgsql-hackers@lists.postgresql.org; Wed, 24 Apr 2024 20:26:45 +0000 Received: by mail-io1-xd2c.google.com with SMTP id ca18e2360f4ac-7da1d81d042so12278639f.0 for ; Wed, 24 Apr 2024 13:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713990403; x=1714595203; darn=lists.postgresql.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=2u0ZT4veYO84+YRFgbCsiTFrHFvxjG7he6h2O5pvmiE=; b=Mzu2hQSd/yYL8ZjuKaA1ACdk4ba4sQ4INE0/LK0eFWazH+FHRjTmmXVIQhmG886cxs /UoRRAmv3+PppHAQjMkb8Jg1r68F0SbwjXFaT/cWGleOgQNmOFzxD/SgboWfoPu6MR5T sUKmeqqUmmu0QtMDh+k2egkUJYEgYM/CrakjMZ/mGOaSQ5+ZoIQbLjR1qqfllNIxJkXk RUOc64vwk8y96YqgpUlOTEEHJ49aSaXO7AvK0N5Iyj1KbokRdp2tVQZxhISwD1v3zGsE yH9xo62Cg2TnEscrW3099nZ+xfL9g38Gc1g5YP6CwEjKZ853o6wEmSB3hRjcCSpZoAPT 4RDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713990403; x=1714595203; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2u0ZT4veYO84+YRFgbCsiTFrHFvxjG7he6h2O5pvmiE=; b=LCn90Kk10xZE3CdWmzEpKGvRfDstErY0oDNoyBQh3m4kiemIux6cdIKemf0jimZyhY 5Pg1scTMLtbXNSZ+3P1KQBnSTJb7l+TVu+ORuqXZyJQpdD5Oa2CogGjPx0JDMLoICkPc ZhtlQsiQ6c2im4bgAxmZfluNHvOLhgWDG9eZQdNJSrnbvBudLUCGbXXdfsSSPSck8RFv 6ht7wY+XHqaUDxeQJaQA4jM7sWcVYhC4PAqtOShGCWq1XIkbwefmXJuOpMfJd21lmNG0 LCiFpS8fL2QlkEsLGBN/5CNbbT4e/hFRpQtBSF4+LwnzbYK4SKmbDw5etjryf+aKSoEH wBOA== X-Gm-Message-State: AOJu0YxdBN94/MX7NTFrtxPLqAlSTUiSSvYzv1k2lnEZ2Onw04dCAWlI aPfKX0YSeOa//+XzzuzcQEEcADYjaXz/kJ6ljZUsWkPz8gT59PxH/rmPuA== X-Google-Smtp-Source: AGHT+IHlZSYIrknnDboFUnZbSMk7vwHJDWX1IrIqgnbSnxPzxiNoYuVQAFSB87wd2XpuKkvRQmCrqQ== X-Received: by 2002:a05:6602:80b:b0:7d6:7131:4c94 with SMTP id z11-20020a056602080b00b007d671314c94mr3647246iow.21.1713990402663; Wed, 24 Apr 2024 13:26:42 -0700 (PDT) Received: from nathanxps13 (162-195-168-172.lightspeed.stlsmo.sbcglobal.net. [162.195.168.172]) by smtp.gmail.com with ESMTPSA id gz14-20020a0566386b0e00b0048492707ba6sm4522364jab.40.2024.04.24.13.26.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Apr 2024 13:26:42 -0700 (PDT) Date: Wed, 24 Apr 2024 15:26:40 -0500 From: Nathan Bossart To: Michael Paquier Cc: Postgres hackers Subject: Re: Partitioned tables and [un]loggedness Message-ID: <20240424202640.GB861150@nathanxps13> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Apr 24, 2024 at 04:17:44PM +0900, Michael Paquier wrote: > - Support ALTER TABLE .. SET LOGGED/UNLOGGED for partitioned tables, > where the command only works on partitioned tables so that's only a > catalog switch. I'm not following what this means. Does SET [UN]LOGGED on a partitioned table recurse to its partitions? Does this mean that you cannot changed whether a single partition is [UN]LOGGED? How does this work with sub-partitioning? > - CREATE TABLE PARTITION OF would make a new partition inherit the > logged ness of the parent if UNLOGGED is not directly specified. This one seems generally reasonable to me, provided it's properly noted in the docs. > - How about ONLY? Would it make sense to support it so as ALTER TABLE > ONLY on a partitioned table does not touch any of its partitions? > Would not specifying ONLY mean that the loggedness of the partitioned > table and all its partitions is changed? That would mean a burst in > WAL when switching to LOGGED, which was a concern when this feature > was first implemented even for a single table, so for potentially > hundreds of them, that would really hurt if a DBA is not careful. I guess ONLY could be a way of changing the default for new partitions without changing whether existing ones were logged. I'm not tremendously concerned about the burst-of-WAL problem. Or, at least, I'm not any more concerned about it for partitioned tables than I am for regular tables. I do wonder if we can improve the performance of setting tables LOGGED, but that's for a separate thread... > - CREATE TABLE does not have a LOGGED keyword, hence it is not > possible through the parser to force a partition to have a permanent > persistence even if its partitioned table uses UNLOGGED. Could we add LOGGED for CREATE TABLE? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com