| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
| Cc: | Melvin Davidson <melvin6925(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, Thomas Kellerer <spam_eater(at)gmx(dot)net> |
| Subject: | Re: BRIN indexes |
| Date: | 2016-01-29 13:21:56 |
| Message-ID: | 20160129132155.GA767307@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Emre Hasegeli wrote:
> >> From the above, may I presume that it is best to cluster (or sort), the
> >> table based on the intended
> >> BRIN column(s) before actually creating the index to insure the pages are
> >> adjacent? If so, should
> >> that not be included in the documentation, instead of implied?
>
> The same question is asked to me at PGConf.DE. I think it would be
> nice to address it in the documentation somehow. Maybe, we should
> also explain how the table is physically organised. It is not clear
> to users what kind of operations would make BRIN more useful.
Grumble.
> > I don't have faith in CLUSTER anyway. Taking exclusive locks and all.
>
> It also requires a btree index. If you can afford to have btree, you
> probably don't need BRIN anyway. Something lighter than CLUSTER which
> can use BRIN would be useful.
What I think would be useful is a way for the BRIN index to guide
location of a new tuple, so that it's put in the right spot right from
the start, instead of having it be moved later.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Leonard B | 2016-01-29 14:17:08 | apt.postgresql.org ubtuntu trusty missing libpq version |
| Previous Message | Emre Hasegeli | 2016-01-29 13:08:28 | Re: BRIN indexes |