From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Declarative partitioning |
Date: | 2016-03-09 00:17:36 |
Message-ID: | CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Sorry for replying so late.
>
No worries! We have jobs to do aside from this.
>
> Everything seemed to go dandy until I tried FOR VALUES (blah , blah],
> where psql wouldn't send the command string without accepting the closing
> parenthesis, :(. So maybe I should try to put the whole thing in '', that
> is, accept the full range_spec in a string, but then we are back to
> requiring full-blown range parse function which I was trying to avoid by
> using the aforementioned grammar. So, I decided to move ahead with the
> following grammar for time being:
>
> START (lower-bound) [ EXCLUSIVE ]
> | END (upper-bound) [ INCLUSIVE ]
> | START (lower-bound) [ EXCLUSIVE ] END (upper-bound) [ INCLUSIVE ]
>
> Where,
>
> *-bound: a_expr
> | *-bound ',' a_expr
>
> Note that in the absence of explicit specification, lower-bound is
> inclusive and upper-bound is exclusive.
>
Thanks for trying. I agree that it would be a full blown range parser, and
I'm not yet advanced enough to help you with that.
So presently partitions that are unbounded on the lower end aren't
possible, but that's a creation syntax issue, not an infrastructure issue.
Correct?
> Okay, perhaps I should not presume a certain usage. However, as you know,
> the usage like yours requires some mechanism of data redistribution (also
> not without some syntax), which I am not targeting with the initial patch.
>
I'm quite fine with limitations in this initial patch, especially if they
don't limit what's possible in the future.
> > Question: I haven't dove into the code, but I was curious about your
> tuple
> > routing algorithm. Is there any way for the algorithm to begin it's scan
> of
> > candidate partitions based on the destination of the last row inserted
> this
> > statement? I ask because most use cases (that I am aware of) have data
> that
> > would naturally cluster in the same partition.
>
> No. Actually the tuple-routing function starts afresh for each row. For
> range partitions, it's binary search over an array of upper bounds. There
> is no row-to-row state caching in the partition module itself.
>
>
bsearch should be fine, that's what I've used in my own custom partitioning
schemes.
Was there a new patch, and if so, is it the one you want me to kick the
tires on?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-03-09 00:19:40 | Re: Performance improvement for joins where outer side is unique |
Previous Message | Alvaro Herrera | 2016-03-09 00:09:10 | Re: pgcrypto: add s2k-count |