Re: Hypothetical indexes using BRIN broken since pg10 - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Hypothetical indexes using BRIN broken since pg10
Date
Msg-id 20191119054025.GE1614@paquier.xyz
Whole thread Raw
In response to Re: Hypothetical indexes using BRIN broken since pg10  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Hypothetical indexes using BRIN broken since pg10  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Fri, Nov 15, 2019 at 12:07:15PM +0900, Michael Paquier wrote:
> So, Heikki, are you planning to work more on that and commit a change
> close to what has been proposed upthread in [1]?  It sounds to me that
> this has the advantage to be non-intrusive and a similar solution has
> been used for GIN indexes.  Moving the redesign out of the discussion,
> is there actually a downsize with back-patching something like
> Heikki's version?

So...  I have been looking at this patch, and indeed it would be nice
to pass down a better value than BRIN_DEFAULT_PAGES_PER_RANGE to be
able to compute the stats in brincostestimate().  Still, it looks also
to me that this allows the code to be able to compute some stats
directly.  As there is no consensus on a backpatch yet, my take would
be for now to apply just the attached on HEAD, and consider a
back-patch later on if there are more arguments in favor of it.  If
you actually test hypopg currently, the code fails when attempting to
open the relation to get the stats now.

Attached are the patch for HEAD, as well as a patch to apply to hypopg
on branch REL1_STABLE to make the module compatible with PG13~.

Any objections?

NB @Julien: perhaps you'd want to apply the second patch to the
upstream repo of hypopg, and add more tests for other index AMs like
GIN and BRIN.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Gareth Palmer
Date:
Subject: Re: [PATCH] Implement INSERT SET syntax
Next
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: Recovery performance of DROP DATABASE with many tablespaces