Message-ID: <54821025.7010201@BlueTreble.com>
Date: Fri, 5 Dec 2014 14:05:57 -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: Robert Haas <robertmhaas@gmail.com>
CC: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Amit Kapila
 <amit.kapila16@gmail.com>, 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>
	<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>
	<CAA4eK1+pJaZGHBeSxKtUd_gNeGjUDMrftmwjGC+PBob-ZFNk-Q@mail.gmail.com>
	<028401d01058$b4b19dd0$1e14d970$@lab.ntt.co.jp>
	<CAA4eK1K=_DxN-ALbDx-u6P=GOr94W04vOJu4qsExNLsKJoBx9g@mail.gmail.com>
	<029e01d0106f$d511eb40$7f35c1c0$@lab.ntt.co.jp>
	<548205E5.7020505@BlueTreble.com>	<54820CE3.7030706@BlueTreble.com>
 <CA+TgmoZx5QoL+QDieHgZou0BaOc-oqNNE2tY1_NG9U-Fd-d9TA@mail.gmail.com>
In-Reply-To: 
 <CA+TgmoZx5QoL+QDieHgZou0BaOc-oqNNE2tY1_NG9U-Fd-d9TA@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/5/14, 2:02 PM, Robert Haas wrote:
> On Fri, Dec 5, 2014 at 2:52 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> The other option would be to use some custom rowtype to store boundary
>> values and have a method that can form a boundary tuple from a real one.
>> Either way, I suspect this is better than frequently evaluating
>> pg_node_trees.
>
> On what basis do you expect that?  Every time you use a view, you're
> using a pg_node_tree.  Nobody's ever complained that having to reload
> the pg_node_tree column was too slow, and I see no reason to suppose
> that things would be any different here.
>
> I mean, we can certainly invent something new if there is a reason to
> do so.  But you (and a few other people) seem to be trying pretty hard
> to avoid using the massive amount of infrastructure that we already
> have to do almost this exact thing, which puzzles the heck out of me.

My concern is how to do the routing of incoming tuples. I'm assuming it'd be significantly faster to compare two tuples than to run each tuple through a bunch of nodetrees.
-- 
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