Subject: Re: Declarative partitioning
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>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <56DF74F0.7060404@lab.ntt.co.jp>
Date: Wed, 9 Mar 2016 09:57:20 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CADkLM=cb7q4TSYQYX4EsMHVK0hjEnBJiA8+XMSSropk2CHwa_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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