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 1lpKGz-00011r-UB for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Jun 2021 00:34:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lpKGy-0005su-8t for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Jun 2021 00:34:44 +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 1lpKGx-0005sf-SZ for pgsql-hackers@lists.postgresql.org; Sat, 05 Jun 2021 00:34:44 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lpKGu-0003mL-FF for pgsql-hackers@postgresql.org; Sat, 05 Jun 2021 00:34:42 +0000 Received: by mail-pf1-x42b.google.com with SMTP id s14so7726901pfd.9 for ; Fri, 04 Jun 2021 17:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=ZuEoJ4bMqKHNXyl+kJq1Sof8THZxrlSOYqMC+3Fb0OQ=; b=htoc/kPFIEkNA3TlAAaDr51u+9h6FipGAINkOejlgkmiDjE5jCX6gTWW/qQXbcRpLK bRCSq3leIq8QUM+L+SjFQvz/ynBuy2Lunn83TNj+WejsWcWyTydDMBOvlbnjZJyEatiJ 6I8c5oHt1lkmM18NY7hp845G1vcQyrsHqLJN1591lKt2S+cPe05sTgnIhuB+R0lQe2Ns cW73/gg7bGVHnvu522fWP96hnbgwl915nf2wM1POJWm2j8ofq57htWffiQM9hkzGgmlX 3mxd68r5ar1Q8nXHKhbBv8dg3ea/YDUv9f7OcSDKgZkyPLCsZhEaf1GaAfBRGO5LhENv WFLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=ZuEoJ4bMqKHNXyl+kJq1Sof8THZxrlSOYqMC+3Fb0OQ=; b=fz/WwsI5XHHvS7jgBFTBtk+chUq0X2VpLlZ0qwxqFqZixzxRFBS9S3+lMyYYG6f8B/ VamhxsYPK439oCOGp5IUjq5pfreW+yrw824ZTb/0j0FYWL+9tts5qIDaD1CFoA1nZtjq kEmWrhZ8st3xFoDDd2IEg14AH45SawS+ZVtfPHfULXs7t0NzD+9pPmzPxOnHUIrXhC56 0zryspoi3/mB36OjCDHKnZ/A2ZL4/32fnpNv13kkaWcqDVDymhZOaKBvzyeiajr/O2lc 76aZZXOiRBftAL0h/aRMRsNh9VBr44P1ZzT/9DNlCg2WDSQlJBDMWVqxs5TNPbrYhvY5 MwXQ== X-Gm-Message-State: AOAM533htf0dU4C4wI4nXCVXnPeU2eKB1Qpel5b8bU+xN0B/HYNLuXrt UXv7gv/rDO2/nmX3XhspwZpZfA== X-Google-Smtp-Source: ABdhPJwaC6XgfJMzWwz/cayZeKDq1h4ixQ1L/eoNRRXlIkauZfdgk+DpVbQLRvKDxspVdx5PgosP4g== X-Received: by 2002:a63:358c:: with SMTP id c134mr7375136pga.114.1622853279199; Fri, 04 Jun 2021 17:34:39 -0700 (PDT) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id y138sm2794007pfc.11.2021.06.04.17.34.37 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 04 Jun 2021 17:34:38 -0700 (PDT) Message-ID: <96b4aa732b2c976f6252e0af4892b8a951964daf.camel@j-davis.com> Subject: Re: alter table set TABLE ACCESS METHOD From: Jeff Davis To: Michael Paquier Cc: Justin Pryzby , pgsql-hackers@postgresql.org, Jacob Champion , Heikki Linnakangas , Ashwin Agrawal , Ashutosh Sharma , Andres Freund , Robert Haas , Amit Kapila , Alvaro Herrera , Dilip Kumar Date: Fri, 04 Jun 2021 17:34:36 -0700 In-Reply-To: References: <20210308010707.GA29832@telsasoft.com> <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com> <20210506202305.GQ27406@telsasoft.com> <1033d6b4b5b42a014cc3f617265ae6e61cb5781b.camel@j-davis.com> <20210506221943.GS27406@telsasoft.com> <3bee08c2ca0fab15d14899afcb19490f29e0ec6f.camel@j-davis.com> <803b32e45baf0b05e5f3fc144383db3a18081693.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, 2021-06-05 at 08:45 +0900, Michael Paquier wrote: > One thing I am wondering is if we should have a dummy_table_am in > src/test/modules/ to be able to stress more this feature. That does > not seem like a hard requirement, but relying only on heap limits a > bit the coverage of this feature even if one changes > default_table_access_method. I agree that a dummy AM would be good, but implementing even a dummy AM is a fair amount of work. Also, there are many potential variations, so we'd probably need several. The table AM API is a work in progress, and I think it will be a few releases (and require a few more table AMs in the wild) to really nail down the API. Regards, Jeff Davis