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 1ksCvL-00042f-4y for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 22:48:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ksCvJ-0002Nb-WC for pgsql-hackers@arkaria.postgresql.org; Wed, 23 Dec 2020 22:48:02 +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 1ksCvJ-0002NF-Lb for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 22:48:01 +0000 Received: from mail-io1-xd33.google.com ([2607:f8b0:4864:20::d33]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ksCvC-0003oN-S3 for pgsql-hackers@lists.postgresql.org; Wed, 23 Dec 2020 22:48:01 +0000 Received: by mail-io1-xd33.google.com with SMTP id y5so608077iow.5 for ; Wed, 23 Dec 2020 14:47:54 -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=LGF2IqoFAx0Ftgva3sOiJol058OcP+Mwwo+hy4rLUvI=; b=lu4pDbW89pbmcTJDv+nAJg8sblHmOQY7S6+uy38U4i6iLxGDBOzfbzG8flQ5aEW3eq 1JyJXIGuQVCnI2rHHfqRvBmAeMS4UC59gFEdk7Ld20rIalv2WHTXchq573xWjoZdtv5m g6E7uZyibBSRBrkdf6gXTTvvTSTyQ1P5REUjaZ6gOB+9c9S8mt7eHNV27eCWHQZAdJdO XsskFj+AXdYk3/THAAi7L7yCRLEvnkWzowrmc9wqYEg3y3ZV5vBrsVnlhRvphfZW/FMd wfRU+4OGn2XVQsHeA1b1QQOLHhdI85UCTLYKT0xewO33MmSKClEPnCvq9MQ4p3Pck8Dw aglQ== 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=LGF2IqoFAx0Ftgva3sOiJol058OcP+Mwwo+hy4rLUvI=; b=Z3/Jvf0kOyFUVLhVsI9wypZ7mYb++Ja7IRcCSOqGtArNu3tVNcg7D2/P+L2X6/+Wwb 5sIkaw2T1ZmjEOFKeT/p8F290/xUclN7HQGU6TdXt74GM9XYQOPZsJJgtlTsI75D7Tnh u58BXJjQ3UAyPvdwjRvaUCG3TY8ltCb5uA6gciksviS6bjmZgKR9GkwDoYzu9cIIQUgK +kq4UeU/40GKQHjuq45ejvNt7hLOAveNJ/bmQi3eMELq6c9/Mc9VFjAlTVaNxLvwWLpT sbA40gn4w/CgNBJSfcOdGDNlhMJUAHS9Nhd5c96Yu4GklWLwzgTMnHeW2A1+1/PQeDec 2V3A== X-Gm-Message-State: AOAM5318HFJSB66vOxzUqkEuI3PyWVbMlM+/ssrvU3FBOZzEIwvLYiEI 0u7kKJO3hRAXmvEsbcldKdwb+Q== X-Google-Smtp-Source: ABdhPJyGzRESCS9egFqZU4yNRodMrxQ5TI3dLpHm2gV/ZBTxBMwp4bk1d6D+8JhBnzzDAliTKJCQgA== X-Received: by 2002:a6b:b7c4:: with SMTP id h187mr23300482iof.76.1608763672678; Wed, 23 Dec 2020 14:47:52 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id y5sm18215627ilh.24.2020.12.23.14.47.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Dec 2020 14:47:51 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id AD0B6800612; Wed, 23 Dec 2020 16:47:49 -0600 (CST) Date: Wed, 23 Dec 2020 16:47:49 -0600 From: Justin Pryzby To: Alvaro Herrera Cc: Michael Paquier , Peter Eisentraut , Alexey Kondratov , Masahiko Sawada , Steve Singer , pgsql-hackers@lists.postgresql.org, Robert Haas , Alexander Korotkov , Masahiko Sawada , Jose Luis Tallon Subject: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly Message-ID: <20201223224749.GT30237@telsasoft.com> References: <20201223222205.GA13552@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201223222205.GA13552@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Dec 23, 2020 at 07:22:05PM -0300, Alvaro Herrera wrote: > Also: it seems a bit weird to me to put the flags inside the options > struct. I would keep them separate -- so initially the options struct > would only have the tablespace OID, on API cleanliness grounds: I don't see why they'd be separate or why it's cleaner ? If the user says REINDEX (CONCURRENTLY, VERBOSE, TABLESPACE ts) , why would we pass around the boolean flags separately from the other options ? > struct ReindexOptions > { > tablepaceOid oid; > }; > extern bool > reindex_relation(Oid relid, bits32 flags, ReindexOptions *options); > But also, are we really envisioning that these routines would have all > that many additional options? Maybe it is sufficient to do just > > extern bool > reindex_relation(Oid relid, bits32 flags, tablespaceOid Oid); That's what we did initially, and Michael suggested to put it into a struct. Which makes the tablespace patches cleaner for each of REINDEX, CLUSTER, VACUUM, since it doesn't require modifying the signature of 5-10 functions. And future patches get to reap the benefit. These are intended to be like VacuumParams. Consider that ClusterOptions is proposed to get not just a tablespaceOid but also an idxtablespaceOid. This was getting ugly: extern void reindex_index(Oid indexId, bool skip_constraint_checks, char relpersistence, int options, Oid tablespaceOid); -- Justin