Re: BRIN indexes

From: Melvin Davidson <melvin6925(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: "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-28 17:41:08
Message-ID: CANu8FizUJV_UQQ1uw8BjyQ9bdKGbf9zWjYoaaNv-=_jDsqt-3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

So, IOW, and the answer to my question is yes, it should be insured that
all pages involved are physically adjacent (by design or by pre-sort)
before creating a BRIN on them.
Further to the point, it is self defeating to have more than one BRIN index
on the table if the columns involved would have mutually non-adjacent
pages.
Therefore, it actually would be good to state that in the documentation,
even it were just a comment.

On Thu, Jan 28, 2016 at 12:31 PM, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com
> wrote:

> On 29 January 2016 at 06:10, Melvin Davidson <melvin6925(at)gmail(dot)com> wrote:
> > With regard to BRIN indexes:
> >
> > http://www.postgresql.org/docs/9.5/interactive/brin-intro.html
> >
> > 62.1. Introduction
> > ....
> > "A block range is a group of pages that are physically adjacent in the
> table; for each block range, some summary info is stored by the index."
> >
> > 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?
>
> I personally think the second sentence of the link to the
> documentation covers this quite well. Namely "BRIN is designed for
> handling very large tables in which certain columns have some natural
> correlation with their physical location within the table."
>
> Examples of this might be something like an "orders" table, where you
> have an orderdate column, probably you'll insert into this table as
> orders are received, so quite possibly the table will be naturally
> ordered in ascending orderdate order. Although UPDATEs might create
> new tuples in some free space elsewhere in the relation, but it's not
> hard to imagine other cases where there's no updates and "natural
> correlation" is persisted.
>
> --
> David Rowley http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>

--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2016-01-28 18:03:01 Re: BRIN indexes
Previous Message Wolfgang Winkler 2016-01-28 17:36:15 Re: Using a german affix file for compound words