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 1jL8cu-0004N5-RU for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 17:00:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jL8ct-0002kd-EK for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2020 17:00:03 +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 1jL8ct-0002kW-2b for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2020 17:00:03 +0000 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jL8cp-0005KX-MW for pgsql-hackers@postgresql.org; Sun, 05 Apr 2020 17:00:02 +0000 Received: by mail-wm1-x32c.google.com with SMTP id i19so13288279wmb.0 for ; Sun, 05 Apr 2020 09:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=hlqGqqeS7dxFI6yrWCZnRbuJSeYzLrfxSbOn/9zQHXg=; b=FjohM+VrRX6EFkxiDpifolpOu7UR5WKLgpMzFPAKs5wlLR3VyB+xBsDJdJtKRooeuG T++8+yCfQ9sgE07SCZ5RhVMm6rGCb8Ued5WpRTN8hSgRkpZDtkcuMZDcoYx0urZ8tk0i wO11ZbLC4gw9jdaMAWGqnFteBH289LLHr0ZNhm0aOgWgHEA1sfEH6unCAhAOYpmALkO0 qYoNnV2JdWmC5/85GSsdjEK8ttNMt+1ILMZpLHo8HXRRcQStuWbTl/SFcOKbmDgeja5Z CViGlmOitFKA+uQGERLZao5ytUR5XJbOUmJn6fBTymFpibXCz3vbAo/BsbcqWRZmYmos YtXA== 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; bh=hlqGqqeS7dxFI6yrWCZnRbuJSeYzLrfxSbOn/9zQHXg=; b=lfdzWFoNnIwwtbNwWQsVqCPFhenXFF/BdbVhtUFxSEnZQp+Klx+G+tFe0heJOy6DCM tqo2prBegB+haRhl/nsNdv8+hFGpbAEFqlfCEQQu+UCjx8hk7pDgDbJ6a8PMbE5nLeOf Cb903sO0NI/wXz8i2Hg6mGgazzm31Q/CE69mqO1dfUm3Cztz0ze2Wwk4q2xc8bmf8t9M ERlSLPVL7easr4m5n0KB+cjDzMLfqnJ8BBH7AhnN2RSXadgHgZqDg9TFMavqfBmX7OsI 6EKHKGbnjS37Fz/woVJS1kG1ZH7+tLje/ns2qqtr6D73EWGe8u3uPdgswlAI/kaC7maW M57A== X-Gm-Message-State: AGi0PuYt0QuC1MWRGbbNYD2VttCm4j8tIVhvyykLay5IsQoOKjK5IZNb UhyDFnMvRoOYW+dBXGdpciQCgw== X-Google-Smtp-Source: APiQypIzn63IB+Efa6t+Dva/cBh9nJ4mDW4H1MQZEPCzAOLUSg1EuCcowVSVjzT0uWpoQgW/1/GgUw== X-Received: by 2002:a05:600c:24a:: with SMTP id 10mr18549365wmj.98.1586105997833; Sun, 05 Apr 2020 09:59:57 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id 106sm11402531wrc.46.2020.04.05.09.59.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Apr 2020 09:59:56 -0700 (PDT) Date: Sun, 5 Apr 2020 18:59:54 +0200 From: Tomas Vondra To: Alexander Korotkov Cc: Michael Paquier , Alvaro Herrera , Tom Lane , Andres Freund , Mark Dilger , pgsql-hackers Subject: Re: WIP: BRIN multi-range indexes Message-ID: <20200405165954.m2odnthc7sbdctwg@development> References: <20190914173049.welhipsj7bijqahm@development> <20190925200748.GA22809@alvherre.pgsql> <20190926190148.piwdqnfc2brargqq@development> <20191201015502.GF2355@paquier.xyz> <20200402022904.xssjyfupdaj2ejyp@development> <20200405155317.rpmkqdj7far7mwkx@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Apr 05, 2020 at 07:33:40PM +0300, Alexander Korotkov wrote: >On Sun, Apr 5, 2020 at 6:53 PM Tomas Vondra > wrote: >> On Sun, Apr 05, 2020 at 06:29:15PM +0300, Alexander Korotkov wrote: >> >On Thu, Apr 2, 2020 at 5:29 AM Tomas Vondra >> > wrote: >> >> On Sun, Dec 01, 2019 at 10:55:02AM +0900, Michael Paquier wrote: >> >> >On Thu, Sep 26, 2019 at 09:01:48PM +0200, Tomas Vondra wrote: >> >> >> Yeah, the opclass params patches got broken by 773df883e adding enum >> >> >> reloptions. The breakage is somewhat extensive so I'll leave it up to >> >> >> Nikita to fix it in [1]. Until that happens, apply the patches on >> >> >> top of caba97a9d9 for review. >> >> > >> >> >This has been close to two months now, so I have the patch as RwF. >> >> >Feel free to update if you think that's incorrect. >> >> >> >> I see the opclass parameters patch got committed a couple days ago, so >> >> I've rebased the patch series on top of it. The pach was marked RwF >> >> since 2019-11, so I'll add it to the next CF. >> > >> >I think this patchset was marked RwF mainly because slow progress on >> >opclass parameters. Now we got opclass parameters committed, and I >> >think this patchset is in a pretty good shape. Moreover, opclass >> >parameters patch comes with very small examples. This patchset would >> >be great showcase for opclass parameters. >> > >> >I'd like to give this patchset a chance for v13. I'm going to make >> >another pass trough this patchset. If I wouldn't find serious issues, >> >I'm going to commit it. Any objections? >> > >> >> I'm an author of the patchset and I'd love to see it committed, but I >> think that might be a bit too rushed and unfair (considering it was not >> included in the current CF at all). >> >> I think the code is correct and I'm not aware of any bugs, but I'm not >> sure there was sufficient discussion about things like costing, choosing >> parameter values (e.g. number of values in the multi-minmax or bloom >> filter parameters). > >Ok! > >> That being said, I think the first couple of patches (that modify how >> BRIN deals with multi-key scans and IS NULL clauses) are simple enough >> and non-controversial, so maybe we could get 0001-0003 committed, and >> leave the bloom/multi-minmax opclasses for v14. > >Regarding 0001-0003 I've couple of notes: >1) They should revise BRIN extensibility documentation section. >2) I think 0002 and 0003 should be merged. NULL ScanKeys should be >still passed to consistent function when oi_regular_nulls == false. > >Assuming we're not going to get 0001-0003 into v13, I'm not so >inclined to rush on these three as well. But you're willing to commit >them, you can count round of review on me. > I have no intention to get 0001-0003 committed. I think those changes are beneficial on their own, but the primary reason was to support the new opclasses (which require those changes). And those parts are not going to make it into v13 ... regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services