| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Vik Fearing <vik(at)2ndquadrant(dot)fr> |
| Cc: | John R Pierce <pierce(at)hogranch(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: 9.5 new features |
| Date: | 2016-01-23 09:55:51 |
| Message-ID: | CAKJS1f-=Ja7rSyjmuzDd0fT-QjNjVS8L7oUZ51wbjOWJ9a-=YQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 23 January 2016 at 22:41, Vik Fearing <vik(at)2ndquadrant(dot)fr> wrote:
> On 01/23/2016 10:28 AM, John R Pierce wrote:
>> anyways, yeah, BRIN sounds very cool for very large tables with
>> relatively stable data.
>
> I have found it particularly efficient when the BRIN index contains all
> columns of the table. Just using it on one or two columns is not a win
> over btree.
I've found it to be very useful for very large INSERT only tables with
a column which increments with each insert, e.g. a timestamp. This
allows large portions on the table to be skipped during a scan, and
also maintains sequential read speeds which I don't think would work
quite as efficiently with btree index performing heap lookups.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | FarjadFarid(ChkNet) | 2016-01-23 10:49:27 | Re: 9.5 new features |
| Previous Message | Vik Fearing | 2016-01-23 09:41:28 | Re: 9.5 new features |