Re: [HACKERS] Minor typo in partition.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Minor typo in partition.c
Date
Msg-id CA+Tgmoa8ot5xPCCpoN_YHve1=Au7HVLMVECzs1sM7tfGGUsqhQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Minor typo in partition.c  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Sat, Apr 15, 2017 at 7:38 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> I waited quite a while for you to review Amit's patches on that
>> thread, but as you never did, I eventually picked it up.
>
> Sorry about that, I guess I was concentrating on things listed on the
> CF app at that time.

No problem from my end, just explaining that I did try to give you an
opportunity to have a crack at it.

>>> Where shall I mention BRIN in that chapter?
>>
>> You never answered my email about why BRIN belongs in that chapter.  I
>> maintain that it doesn't, because BRIN is not a partitioning method.
>
> BRIN is a method of speeding up queries by skipping large chunks of
> tables, just the same as declarative partitioning.

Well, *any* index speeds up queries by skipping large chunks of a
table; that's not unique to BRIN.  I suppose if you tilt your head
right, you could view partitioning as a very coarse-grained kind of
indexing; there are echoes of that in the code.

In my opinion, the relationship between BRIN and partitioning is that
both features are concerned with locality, but partitioning (and
inheritance, and UNION ALL views) create locality, whereas BRIN takes
advantage of locality created by some other means (or locality that
exists by chance).  However, I consider those things different enough
that I wouldn't document them together.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [HACKERS] Some thoughts about SCRAM implementation
Next
From: Thomas Mercieca
Date:
Subject: [HACKERS] Extracting GiST index structure stats?