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 1nF2jR-0002pX-Ol for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Feb 2022 23:38:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nF2jQ-0008RM-Kf for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Feb 2022 23:38:40 +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 1nF2jQ-0008RD-6K for pgsql-hackers@lists.postgresql.org; Tue, 01 Feb 2022 23:38:40 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nF2jN-0000Tv-Uz for pgsql-hackers@postgresql.org; Tue, 01 Feb 2022 23:38:39 +0000 Received: by mail-pj1-x1029.google.com with SMTP id h12so18595028pjq.3 for ; Tue, 01 Feb 2022 15:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=ExxZs/wlzyq2h0gJ77TNoiUqRi06mLf9lQHbBZTOUR4=; b=Ze0cRNg0Nac1GIDzO0J1KGAs/TYnDb2y1+YHJ3Gkxr55v3ooQeHQ95c6bo/bZfbU3f t3Wuz90xvbG1azveLnF8bG1axgGPTB/bboCwAUNe1sKftIIW9aPmTNUOsOv1pmNKtaib D9AA4RK3flQknqNN/ZXQjTi6sXr8G4EEt5U4dz3nUVwc8i8IUkPh7q0XYNFjV9zcdqJ7 IJgY6H7IlaPE5iX8ThkLyiPjWo5FqESqjWlKgQBsHhYPhFF/Cj6UMy1fTwBmI7upr1hq m1QZdGj4o+BDKUu8oWiYYvYk/LgNX2wAoTRqO2sqprYBeaOZa6VAOfGBBd/GB2BRXqIr vipQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=ExxZs/wlzyq2h0gJ77TNoiUqRi06mLf9lQHbBZTOUR4=; b=Dhjx24l+V8fFS0F3sjItNOaqtDpXa9vEwOcHN6y/Id0VsATc/T8ztbgzVwWW+0Jbrl /fb1isOwzRJvwSbdbDaI52D04qcE8VaS0bLDCEPt7PLExm9trmYCooGbs1bvUytVhUbW N/D2LmcFRd3JGADdPxBsyu2oekm72xjALrRlE6j7dWmf0YYlN8gQWHy8rxawtjUU99iW WYrf5rdUbYkRq7QB4gHU30ZQbYZ/0phjo0gHkTG/yPR9lHJnHtELtnQg39b/QDB4xE+C rS/SKvoovgaOhMeeuQLEDo6AcFkCcLkpdnzAc9wXXF3lEK1fSGFSRlLCJque9Nzflb9l TVFw== X-Gm-Message-State: AOAM531nqt9w+qhSs7eDwrjkOdE89MCCxFF5ZjcfkiwJitCbTg6T/oUU tQuv3/g4W+6yGxDuSJWeo283rw== X-Google-Smtp-Source: ABdhPJwIfiBv5CTu41OKDoIaXmh5V9xZQ+kojBLhAo6KpWSFtGuJm3eVYAqlAGJmwrsk56CW45M8WQ== X-Received: by 2002:a17:903:283:: with SMTP id j3mr27899605plr.124.1643758715659; Tue, 01 Feb 2022 15:38:35 -0800 (PST) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id mg17sm3967176pjb.19.2022.02.01.15.38.33 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 Feb 2022 15:38:34 -0800 (PST) Message-ID: Subject: Re: Extensible Rmgr for Table AMs From: Jeff Davis To: Julien Rouhaud Cc: pgsql-hackers@postgresql.org, Andres Freund , Amit Kapila , Tom Lane , Simon Riggs Date: Tue, 01 Feb 2022 15:38:32 -0800 In-Reply-To: <20220201124550.gnhpw7iytc4da5tq@jrouhaud> References: <8a1b1ab033342433b1f827fee04ee562231fdb80.camel@j-davis.com> <20220118095332.6xtlcjoyxobv6cbk@jrouhaud> <721eeefbd24c55015739ea75c0a233345e13e0b5.camel@j-davis.com> <20220201043938.r5s35loehsi27saj@jrouhaud> <20220201124550.gnhpw7iytc4da5tq@jrouhaud> 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 Tue, 2022-02-01 at 20:45 +0800, Julien Rouhaud wrote: > On Tue, Feb 01, 2022 at 12:39:38PM +0800, Julien Rouhaud wrote: > > > > Other than that the patch looks good to me, as you said we just > > need a decision > > on whether custom rmgrs are wanted or not. > > One last thing, did you do some benchmark with a couple custom rmgr > to see how > much the O(n) access is showing up in profiles? What kind of a test case would be reasonable there? You mean having a lot of custom rmgrs? I was expecting that few people would have more than one custom rmgr loaded anyway, so a sparse array or hashtable seemed wasteful. If custom rmgrs become popular we probably need to have a larger ID space anyway, but it seems like overengineering to do so now. Regards, Jeff Davis