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
