Message-ID: <547EC6D3.1030309@BlueTreble.com>
Date: Wed, 3 Dec 2014 02:16:19 -0600
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, 'Robert Haas'
 <robertmhaas@gmail.com>
CC: 'Andres Freund' <andres@2ndquadrant.com>, 'Alvaro Herrera'
 <alvherre@2ndquadrant.com>, 'Bruce Momjian' <bruce@momjian.us>, 'Pg Hackers'
 <pgsql-hackers@postgresql.org>
Subject: Re: On partitioning
References: <20140829155607.GF7705@eldon.alvh.no-ip.org>
	<20141013192755.GC21267@momjian.us>
	<20141013193838.GZ7043@eldon.alvh.no-ip.org>
	<20141013194317.GF21267@momjian.us>
	<010801cff1ba$f3f16b90$dbd442b0$@lab.ntt.co.jp>
	<20141027092933.GU1791@alvin.alvh.no-ip.org>
	<20141027114421.GA31497@awork2.anarazel.de>
	<01b001cff270$d470b990$7d522cb0$@lab.ntt.co.jp>
	<20141028100629.GE2639@awork2.anarazel.de>
	<CA+TgmoaHPXfStSk2QERkWkWPnc63HRDgn=+9Nwt+HTd-=dUv+Q@mail.gmail.com>
	<053501cffa30$ecdf8700$c69e9500$@lab.ntt.co.jp>
	<CA+TgmobN+DT_=hj3NkXZgSv157-W24YaZ50oFdRbhS493covzg@mail.gmail.com>
	<066501cffd52$3d919390$b8b4bab0$@lab.ntt.co.jp>
	<CA+TgmoZqndQQQY1U0OBxUOJy1RE_MAawJErghNB7RM8MPgCYDg@mail.gmail.com>
	<032601d00471$ea6f4280$bf4dc780$@lab.ntt.co.jp>
	<CA+TgmoZ-HJOTPfZcnPOh27881xn4N1QGtY7J4nG+v6tV9cJjNw@mail.gmail.com>
	<04da01d00917$2dde1010$899a3030$@lab.ntt.co.jp>
 <CA+TgmoaU+0EN-XsAT1O+64xrENNJiKPgem+Q1hWzz7a=1MYrDA@mail.gmail.com>
 <015b01d00eab$56d37700$047a6500$@lab.ntt.co.jp>
In-Reply-To: <015b01d00eab$56d37700$047a6500$@lab.ntt.co.jp>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 12/2/14, 9:43 PM, Amit Langote wrote:
>> >What is an overflow partition and why do we want that?
>> >
> That would be a default partition. That is, where the tuples that don't belong elsewhere (other defined partitions) go. VALUES clause of the definition for such a partition would look like:
>
> (a range partition) ... VALUES LESS THAN MAXVALUE
> (a list partition) ... VALUES DEFAULT
>
> There has been discussion about whether there shouldn't be such a place for tuples to go. That is, it should generate an error if a tuple can't go anywhere (or support auto-creating a new one like in interval partitioning?)

If we are going to do this, should the data just go into the parent? That's what would happen today.

FWIW, I think an overflow would be useful, but there should be a way to (dis|en)able it.

>> >What are you going to do if the partitioning key has two columns of
>> >different data types?
>> >
> Sorry, this totally eluded me. Perhaps, the 'values' needs some more thought. They are one of the most crucial elements of the scheme.
>
> I wonder if your suggestion of pg_node_tree plays well here. This then could be a list of CONSTs or some such... And I am thinking it's a concern only for range partitions, no? (that is, a multicolumn partition key)
>
> I think partkind switches the interpretation of the field as appropriate. Am I missing something? By the way, I had mentioned we could have two values fields each for range and list partition kind.

The more SQL way would be records (composite types). That would make catalog inspection a LOT easier and presumably make it easier to change the partitioning key (I'm assuming ALTER TYPE cascades to stored data). Records are stored internally as tuples; not sure if that would be faster than a List of Consts or a pg_node_tree. Nodes would theoretically allow using things other than Consts, but I suspect that would be a bad idea.

Something else to consider... our user-space support for ranges is now rangetypes, so perhaps that's what we should use for range partitioning. The up-side (which would be a double-edged sword) is that you could leave holes in your partitioning map. Note that in the multi-key case we could still have a record of rangetypes.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


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