Re: On partitioning

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On partitioning
Date: 2014-12-05 20:02:53
Message-ID: CA+TgmoZx5QoL+QDieHgZou0BaOc-oqNNE2tY1_NG9U-Fd-d9TA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Dec 5, 2014 at 2:52 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-12-05 20:04:01 Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Previous Message Jim Nasby 2014-12-05 19:52:03 Re: On partitioning