pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: José Luis Tallón <jltallon@adv-solutions.net>
To: Claudio Freire <klaussfreire@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: On partitioning
Date: Mon, 15 Dec 2014 12:09:45 +0100
Message-ID: <548EC179.6080002@adv-solutions.net> (raw)
In-Reply-To: <CAGTBQpZBbfOQOmncJDUP0rsYEBYcRkp_ymACRs5B1Mucih1Ccg@mail.gmail.com>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (169+ messages)  latest in thread

Message-ID: <548EC179.6080002@adv-solutions.net>
Permalink:  ../548EC179.6080002@adv-solutions.net/
Also on:    postgresql.org/message-id/548EC179.6080002@adv-solutions.net

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: jltallon@adv-solutions.net, klaussfreire@gmail.com, Langote_Amit_f8@lab.ntt.co.jp, alvherre@2ndquadrant.com, josh@agliodbs.com, tgl@sss.pgh.pa.us
  Subject: Re: On partitioning
  In-Reply-To: <548EC179.6080002@adv-solutions.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox