> > 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?
