Re: BRIN index which is much faster never chosen by planner

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: BRIN index which is much faster never chosen by planner
Дата
Msg-id CAKJS1f_JPstZU-R5D5J7i7X4VSETkoPbcXpf_nDhiAzEpy8P2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BRIN index which is much faster never chosen by planner  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: BRIN index which is much faster never chosen by planner
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Block level parallel vacuum