Re: BRIN index which is much faster never chosen by planner - Mailing list pgsql-hackers

From David Rowley
Subject Re: BRIN index which is much faster never chosen by planner
Date
Msg-id CAKJS1f_JPstZU-R5D5J7i7X4VSETkoPbcXpf_nDhiAzEpy8P2w@mail.gmail.com
Whole thread Raw
In response to Re: BRIN index which is much faster never chosen by planner  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Wed, 16 Oct 2019 at 11:40, Justin Pryzby <pryzby@telsasoft.com> wrote:
> It didn't occur to me at the time, but that would also allow
> creating numerous, partial BRIN indices, each of which would have separate
> correlation computed over just their "restricted range", which *might* also
> handle your case, depending on how packed your data is.

Perhaps I've misunderstood you, but the correlation that's used is per
column, not per index. The only way to have it calculate multiple
correlations would be to partition the table. There'd be a correlation
for the column on each partition that way.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: BRIN index which is much faster never chosen by planner
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum