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?
On 23 January 2016 at 09:49, John R Pierce <pierce@hogranch.com> wrote: > one of my coworkers says he thought that 9.5 has some enhancements in > partitioning, but looking at the release notes I don't see anything specific > ? do BRIN's play into partitioned tables ? > > in our case, we partition very large 'event' tables by week with 6 > month retention....
BRIN can be seen as a form of "automatic partitioning", and I have seen it described as such in documents relating to the BRIN project, so perhaps that description has made its way further afield and that's maybe what your coworker heard about.
If you view the inheritance partitioning feature as a method of eliminating scans of partitions which can be proved unneeded at planning time, then BRIN can eliminate blocks from a scan of a single relation (or rather "pages_per_range") during execution time. So I agree with the "automatic partitioning" description.