Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3ZJ9-00056w-Kg for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 05:51:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j3ZIA-00088m-7f for pgsql-hackers@arkaria.postgresql.org; Mon, 17 Feb 2020 05:50:02 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j3ZI9-00087v-4Q for pgsql-hackers@lists.postgresql.org; Mon, 17 Feb 2020 05:50:01 +0000 Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j3ZI1-0001CA-HI for pgsql-hackers@postgresql.org; Mon, 17 Feb 2020 05:49:59 +0000 Received: by mail-yb1-xb2f.google.com with SMTP id p123so8166191ybp.2 for ; Sun, 16 Feb 2020 21:49:53 -0800 (PST) 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=2u2a01bfxthgYK0gRQgmmYbgfX8YcFa6MsAwSL4nYvo=; b=ekv9Z99GuzM1fa6w39CpQxRhVIGl6Tlmn54oSgO9azwouswVppFN79KDZDnBJ5NVNg Qx4NJoP8oniNdktFFVyiTtEfeHhRaf6aMHUcqfBmZGU5Qk+FoAhMqb8fU0fK0q/Hn4a6 z+rUQoDJLgTYjfm/2FPrxcj6Kd66tSRVSpvL+gHvC0I8FQunHFgXfYINqkdNFZcMFHAO knA/aDC0dbjz4gIt/D7h7kF81WgcSqC+M7Sv3c24WHPPvGr8OnGv9thkiQW3CwdFVz+e OyIqtLihZ9D1EfzfI0d5Lwt14I2712tl8Yr6z8wIjQIxugu22RuaWYmrY17XhuSUrLHE 1Emw== 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=2u2a01bfxthgYK0gRQgmmYbgfX8YcFa6MsAwSL4nYvo=; b=ObfAg47R3EwCMp03nO8G/9sw2rlwRcEVyaLExgIiWrzStqZrdbMOrr1MgYxaeGW3C4 ygC0N9EpA3rDTJfQhv3qh512sKX340g27FVrkET1WkF2pOzenKplP4A4JefDoVzZ+p25 kpT23L7OGMEysHcpSccQef4TUWr6CUHAjedVjJcqeMHyv82/zYUlhuySPGp09j5iXsqS u11q2UdM92rcwgnirsRrATqCQwQGYYPsio5Bz9fFp7c5eoWto57hD5/ik5RjlNxD4Y36 /Z1tWStDdMTZBwtXGX/r8azTpAX/YFJz2xZ167pUCbMKUe+DcQLvcSnCIUUsQj9PfFll TuPg== X-Gm-Message-State: APjAAAV8PjGikDk6FpZt+T35QtYSFkW47/6bCLz/WU2zPr8TSNZnUmm6 dTSg4p9eFjrHDRB/VRfB+qkiig== X-Google-Smtp-Source: APXvYqz0vM0/Z49l4ifl6/vd2qWt3cfCOChvVE/ECOoWz3qt1R4MXi+o+0OIRCF0U+bd1YNt+64BSg== X-Received: by 2002:a5b:106:: with SMTP id 6mr14286541ybx.83.1581918592738; Sun, 16 Feb 2020 21:49:52 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id d22sm5926087ywb.77.2020.02.16.21.49.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Feb 2020 21:49:51 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 07A84800926; Sun, 16 Feb 2020 23:49:49 -0600 (CST) Date: Sun, 16 Feb 2020 23:49:49 -0600 From: Justin Pryzby To: Amit Langote Cc: Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: ALTER tbl rewrite loses CLUSTER ON index (consider moving indisclustered to pg_class) Message-ID: <20200217054949.GN31889@telsasoft.com> References: <20200206144426.GH403@telsasoft.com> <20200206172447.GA28041@alvherre.pgsql> <20200207143935.GP403@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Mon, Feb 17, 2020 at 02:31:42PM +0900, Amit Langote wrote: > Hi Justin, > > On Fri, Feb 7, 2020 at 11:39 PM Justin Pryzby wrote: > > On Thu, Feb 06, 2020 at 02:24:47PM -0300, Alvaro Herrera wrote: > > > On 2020-Feb-06, Justin Pryzby wrote: > > > > > > > I wondered if it wouldn't be better if CLUSTER ON was stored in pg_class as the > > > > Oid of a clustered index, rather than a boolean in pg_index. > > > > > > Maybe. Do you want to try a patch? > > > > I think the attached is 80% complete (I didn't touch pg_dump). > > > > One objection to this change would be that all relations (including indices) > > end up with relclustered fields, and pg_index already has a number of bools, so > > it's not like this one bool is wasting a byte. > > > > I think relisclustered was a's clever way of avoiding that overhead (c0ad5953). > > So I would be -0.5 on moving it to pg_class.. In case there's any confusion: "a's" was probably me halfway changing "someone's" to "a". > Are you still for fixing ALTER TABLE losing relisclustered with the > patch we were working on earlier [1], if not for moving relisclustered > to pg_class anymore? Thanks for remembering this one. I think your patch is the correct fix. I forgot to say it, but moving relisclustered to pg_class doesn't help to avoid losting indisclustered: it still needs a fix just like this. Anyway, I withdrew my suggestion for moving to pg_class, since it has more overhead, even for pg_class rows for relations which can't have indexes. > I have read elsewhere [2] that forcing ALTER TABLE to rewrite in > clustered order might not be a good option, but maybe that one is a > more radical proposal than this. Right; your fix seems uncontroversial. I ran into this (indisclustered) bug while starting to write that patch for "ALTER rewrite in clustered order". -- Justin