Message-ID: <548EC179.6080002@adv-solutions.net>
Date: Mon, 15 Dec 2014 12:09:45 +0100
From: =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <jltallon@adv-solutions.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.0
MIME-Version: 1.0
To: Claudio Freire <klaussfreire@gmail.com>,
 Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
CC: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Josh Berkus <josh@agliodbs.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: On partitioning
References: 
 <CAA4eK1LcDLmOfw3Y4L9FeAn+pMcLg6OLSTK45G9SBQUvO4tZYQ@mail.gmail.com>
	<CA+TgmoYqwOmL=ykspWmwfFivwA2T3gzyEo_94YZd3L3WpLau4g@mail.gmail.com>
	<007b01d015c6$373c21e0$a5b465a0$@lab.ntt.co.jp>
	<CA+TgmoY=aa2eGzTHn+cepnoz4Exj6bhrkNkghFxSxO84V_WroA@mail.gmail.com>
	<CA+TgmobH--E+GkGHsprjN-e_4-YR4208pmE9zp90sEjBjDBDMg@mail.gmail.com>
	<CAGTBQpaqEbSO+=s1xod1G6xfawc1RRnYEL3jGp870h7APnCgGg@mail.gmail.com>
	<9766.1418422242@sss.pgh.pa.us>
	<WM!5674e59aab89034f672b7668897d87b46824a54cca29a62ba08c1af0387796e192e949d0345717737e6887fc6cabf78c!@asav-3.01.com>
	<548B6EE3.3020309@agliodbs.com>
	<CAGTBQpby6DG1E1T+9wfGzMat46OWCxmQ5h-AEr6YzA=iYd5dbQ@mail.gmail.com>
	<20141213020946.GG1768@alvh.no-ip.org>
	<001601d0180c$a212f550$e638dff0$@lab.ntt.co.jp>
 <CAGTBQpZBbfOQOmncJDUP0rsYEBYcRkp_ymACRs5B1Mucih1Ccg@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpZBbfOQOmncJDUP0rsYEBYcRkp_ymACRs5B1Mucih1Ccg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 12/15/2014 07:42 AM, Claudio Freire wrote:
> [snip]

> If you do that, you start with empty partitions, and each insert 
> updates the BRIN tuple. Avoiding concurrency loss in this case would 
> be tricky, but in theory this could allow very general partition 
> exclusion. In fact it could even work with constraint exclusion right 
> now: you'd have a single-tuple BRIN index for each partition and 
> benefit from it. But you don't need to pay the price of updating BRIN 
> indexes, as min-max tuples for each partition can be produced while 
> creating the partitions if the syntax already provides the 
> information. Then, it's just a matter of querying this meta-data which 
> just happens to have the form of a BRIN tuple for each partition.

Yup. Indeed this is the way I outlined in my previous e-mail.

The only point being: Why bother with BRIN when we already have the 
range machinery, and it's trivial to add pointers to partitions from 
each range?

I suggested that BRIN would solve a situation when the amount of 
partitions is huge (say, thousands) and we might need to be able to 
efficiently locate the appropriate partition. In this situation, a 
linear search might become prohibitive, or the data structure (a simple 
B-Tree, maybe) become too big to be worth keeping in memory. This is 
where being able to store the "partition index" on disk would be 
interesting.

Moreover, I guess that ---by using this approach 
(B-Tree[range]->partition_id and/or BRIN)--- we could efficiently answer 
the question "do we have any tuple with this key in some partition?" 
which AFAICS is pretty close to us having "global indexes".


Regards,

     / J.L.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers