| From: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(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:08:28 |
| Message-ID: | CAE2gYzyHtY3hVemYCbigXXgroeYcqHZuRkpdFhpxQHQ16PYhgA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
>> 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.
> 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2016-01-29 13:21:56 | Re: BRIN indexes |
| Previous Message | Kent Tenney | 2016-01-29 12:13:33 | import plpy |