| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Michael Lewis <mlewis(at)entrata(dot)com>, Jeremy Finzel <finzelj(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: BRIN index which is much faster never chosen by planner |
| Date: | 2019-10-15 22:46:49 |
| Message-ID: | CAKJS1f_JPstZU-R5D5J7i7X4VSETkoPbcXpf_nDhiAzEpy8P2w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 16 Oct 2019 at 11:40, Justin Pryzby <pryzby(at)telsasoft(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-10-16 01:19:42 | Re: [HACKERS] Block level parallel vacuum |
| Previous Message | David Rowley | 2019-10-15 22:43:52 | Re: BRIN index which is much faster never chosen by planner |