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 1lHEgp-0002No-43 for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Mar 2021 23:44:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lHEgm-0004kX-Mx for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Mar 2021 23:44:28 +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 1lHEgl-0004kQ-Kh for pgsql-hackers@lists.postgresql.org; Tue, 02 Mar 2021 23:44:28 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lHEge-0002dq-QY for pgsql-hackers@lists.postgresql.org; Tue, 02 Mar 2021 23:44:26 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id AEC74A7C; Tue, 2 Mar 2021 18:44:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 02 Mar 2021 18:44:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=8vrdIEe7slO2iWuvG6dzS8xo9mPlPmYcQ1MgdXNBcBc=; b=S4Mh/7w0 lXh22zXZ2nylftHavFaVK62LGvepqgGDv2woLpzOtm2wLqqG0e6U6oKGUF72v7xI L8C3+LsP6LyKYSh9H2mOv6CG6ySfrO9HMJ+udNPVnfgcj6kPf/Gxa/jH5mCBnU1d jUo/GxMe1furz/+PPN/JVPUkNytWk0p3kWyYcNGnmTTRHlMonxstSYqTh5RBGwy9 0165HV2NFKUehzJ3K2+gEXSWkPm09mufEt/ED/GCD14VYLl7H2wOq3vvBY6bnPjD Vlc5yoncb9f9cPTRKqZ0Lr1Gx+ADtHfA1B7XHKn8yDAK9M+yGOuvf+31/ZEj5/fl rmaJQz83Li2Zvg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtuddgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesthekredttderudenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepueffhfejieeuueffgedvudekgeeltdeviedvieeufeei ieevgfetheeufeethedvnecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id B36471080057; Tue, 2 Mar 2021 18:44:17 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E4D1C2A14F6; Tue, 2 Mar 2021 20:44:14 -0300 (-03) Date: Tue, 2 Mar 2021 20:44:14 -0300 From: Alvaro Herrera To: Tomas Vondra Cc: John Naylor , PostgreSQL Hackers Subject: Re: WIP: BRIN multi-range indexes Message-ID: <20210302234414.GA30716@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2021-Mar-03, Tomas Vondra wrote: > 1) The 0001 patch allows passing of all scan keys to BRIN opclasses, > which is needed for the minmax-multi to work. But it also modifies the > existing opclasses (minmax and inclusion) to do this - but for those > opclasses it does not make much difference, I think. Initially this was > done because the patch did this for all opclasses, but then we added the > detection based on number of parameters. So I wonder if we should just > remove this, to make the patch a bit smaller. It'll also test the other > code path (for opclasses without the last parameter). I think it makes sense to just do them all in one pass. I think trying to keep the old way working just because it's how it was working previously does not have much benefit. I don't think we care about the *patch* being small as much as the resulting *code* being as simple as possible (but no simpler). > 2) This needs bsearch_arg, but we only have that defined/used in > extended_statistics_internal.h - it seems silly to include that here, as > this has nothing to do with extended stats, so I simply added another > prototype (which gets linked correctly). But, I suppose a better way > would be to define our "portable" variant pg_bsearch_arg, next to > pg_qsort etc. Yeah, I think it makes sense to move bsearch_arg to a place where it's more generally accesible (src/port/bsearch_arg.c I suppose), and make both places use that. -- Álvaro Herrera Valdivia, Chile