Re: [HACKERS] Documentation improvements for partitioning - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [HACKERS] Documentation improvements for partitioning
Date
Msg-id CANP8+j+q_nDg6KsBxJvMW2+cXay+tpktoKmN7Gf3wgTgX_5_Ow@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Documentation improvements for partitioning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Documentation improvements for partitioning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 22 February 2017 at 02:14, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Feb 21, 2017 at 2:03 AM, Bruce Momjian <bruce@momjian.us> wrote:
>> I have to admit my reaction was similar to Simon's, meaning that the
>> lack of docs is a problem, and that the limitations are kind of a
>> surprise, and I wonder what other surprises there are.
>
> Did you read my message upthread pointing out that the initial commit
> contained hundreds of lines of documentation?  I agree that it would
> be bad if table partitioning got committed with no documentation, but
> that did not happen.

You seem a little defensive about some reasonable review comments.
While its true that the patch had syntax documentation, there was no
user design documentation which explained how it worked to allow
objective review. Had I been able to provide input without reading
every email message, I would have done so earlier.


Amit,

The features I consider very important in the first release are
1. Declarative syntax (we have this!)
2. Tuple routing on INSERT/COPY (we have this!)
3. O(1) partition elimination for simple = queries
4. PRIMARY KEY defined using a) distinct set of UNIQUE constraints on
each partition, b) partition key

2 and 3 are intimately connected because they would both use the same
in-memory data for bsearch, so the code should be almost identical.

4 is important for Foreign Keys and Logical Replication

As missing items, features 3 and 4 seem achievable in this release,
potentially in restricted form. I think we should probably avoid
trying to UPDATE rows from one partition to another in this release,
since that seems likely to be buggy and seems like would only be
needed in relatively few cases.

Let me know if I can help with these.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog
Next
From: Nico Williams
Date:
Subject: Re: [HACKERS] Make subquery alias optional in FROM clause