On Sun, Mar 03, 2019 at 07:29:26AM +0300, Alexander Korotkov wrote:
>On Sun, Mar 3, 2019 at 12:25 AM Tomas Vondra
><tomas.vondra@2ndquadrant.com> wrote:
>> I've looked at that patch only very briefly so far, but I agree it's
>> likely a better solution than what my patch does at the moment (which I
>> agree is a misuse of the AM-level options). I'll take a closer look.
>>
>> I agree it makes sense to re-use that infrastructure for this patch, but
>> I'm hesitant to rebase it on top of that patch right away. Because it
>> would mean this thread dependent on it, which would confuse cputube,
>> make it bitrot faster etc.
>>
>> So I suggest we ignore this aspect of the patch for now, and let's talk
>> about the other bits first.
>
>Works for me. We don't need to make the whole work made by this patch
>to be dependent on opclass parameters. It's OK to ignore this aspect
>for now and come back when opclass parameters get committed.
>
Attached is this patch series, rebased on top of current master and the
opclass parameters patch [1]. I previously planned to keep those two
efforts separate for a while, but I decided to give it a try and the
breakage is fairly minor so I'll keep it this way - this patch has zero
chance of getting committed with the opclass parameters patch anyway.
Aside from rebase and changes due to adopting opclass parameters, the
patch is otherwise unchanged.
0001-0004 are just the opclass parameters patch series.
0005 adds opclass parameters to BRIN indexes (similarly to what the
preceding parts to for GIN/GiST indexes).
0006-0010 are the original patch series (BRIN tweaks, bloom and
multi-minmax) rebased and switched to opclass parameters.
So now, we can do things like this:
CREATE INDEX x ON t USING brin (
col1 int4_bloom_ops(false_positive_rate = 0.05),
col2 int4_minmax_multi_ops(values_per_range = 16)
) WITH (pages_per_range = 32);
and so on. I think the patch [1] works fine - I only have some minor
comments, that I'll post to that thread.
The other challenges (e.g. how to pick the values for opclass parameters
automatically, based on the data) are still open.
regards
[1] https://www.postgresql.org/message-id/flat/d22c3a18-31c7-1879-fc11-4c1ce2f5e5af%40postgrespro.ru
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
