pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Declarative partitioning
Date: Wed, 9 Mar 2016 09:57:20 +0900
Message-ID: <56DF74F0.7060404@lab.ntt.co.jp> (raw )
In-Reply-To: <CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com >
References: <55D3093C.5010800@lab.ntt.co.jp >
<563341AE.5010207@lab.ntt.co.jp >
<CA+TgmobUi=u1TswwFoi+TU_+XZvJhTrxG-JgZ0OrJmOe7cX87g@mail.gmail.com >
<564EE560.60106@lab.ntt.co.jp >
<CANP8+jJubWHHWZ_WVw4U1uKuLMpuBYhh+3+Mq+c6fz-QMaQ6Jw@mail.gmail.com >
<CA+HiwqENLcoU-Z9QAr=cXKLgb7DnqQO1KYftuNRhODYSJDNHrQ@mail.gmail.com >
<20151120114446.GN614468@alvherre.pgsql >
<CA+TgmoaCtvChjt=xky-P4anEyTWjnUm9xrgo6CpRaN6wPmM7mw@mail.gmail.com >
<566E6C48.9080500@lab.ntt.co.jp >
<CA+TgmoZZMfcf16YaHuhP1Vk=j8PDFeHCvfj+FJQd+eFhs+7P8A@mail.gmail.com >
<5678ACBC.8050809@lab.ntt.co.jp >
<5698CE6D.3070907@lab.ntt.co.jp >
<CA+TgmoY9C_XxbngCd9TtbEuwhu+4oHjeHt+QSzs-6bM=oY4f-w@mail.gmail.com >
<56C55973.80309@lab.ntt.co.jp >
<CADkLM=fz4SRiaLggFctOcJegpcjxaWPwCyi6YDwq9Wnceno7=w@mail.gmail.com >
<56CD6598.4090302@lab.ntt.co.jp >
<CADkLM=f1zyL-cV_LK8GpXv=iS_=VbHs8bernUMa+8yHtUXjebQ@mail.gmail.com >
<56DE2D4B.1040001@lab.ntt.co.jp >
<CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com >
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Hi,
On 2016/03/09 9:17, Corey Huinker wrote:
>>
>> Sorry for replying so late.
> No worries! We have jobs to do aside from this.
Thanks!
>> 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?
In case it wasn't apparent, you can create those:
FOR VALUES END (upper-bound) [INCLUSIVE]
which is equivalent to:
FOR VALUES '(, upper-bound)' or FOR VALUES '(, upper-bound]'
>>> 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?
You didn't miss any. I need a little more time to send the next revision
with significant design overhaul.
Thanks,
Amit
--
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 (161+ messages) latest in thread
Message-ID: <56DF74F0.7060404@lab.ntt.co.jp>
Permalink: ../56DF74F0.7060404@lab.ntt.co.jp/
Also on: postgresql.org/message-id/56DF74F0.7060404@lab.ntt.co.jp
copy link · copy postgr.es
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: Langote_Amit_f8@lab.ntt.co.jp, corey.huinker@gmail.com, robertmhaas@gmail.com
Subject: Re: Declarative partitioning
In-Reply-To: <56DF74F0.7060404@lab.ntt.co.jp>
* 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