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

help / color / mirror / Atom feed
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: On partitioning
Date: Wed, 3 Dec 2014 02:16:19 -0600
Message-ID: <547EC6D3.1030309@BlueTreble.com> (raw)
In-Reply-To: <015b01d00eab$56d37700$047a6500$@lab.ntt.co.jp>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (169+ messages)  latest in thread

Message-ID: <547EC6D3.1030309@BlueTreble.com>
Permalink:  ../547EC6D3.1030309@BlueTreble.com/
Also on:    postgresql.org/message-id/547EC6D3.1030309@BlueTreble.com

 · 

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: Jim.Nasby@BlueTreble.com, Langote_Amit_f8@lab.ntt.co.jp, robertmhaas@gmail.com, andres@2ndquadrant.com, alvherre@2ndquadrant.com, bruce@momjian.us
  Subject: Re: On partitioning
  In-Reply-To: <547EC6D3.1030309@BlueTreble.com>

* 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