On Thu, Oct 26, 2017 at 1:17 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > It can perhaps taught to not make that conclusion by taking into account > the default partition's partition constraint, which includes constraint > inherited from the parent, viz. 1 <= col1 < 50001. To do that, it might > be possible to summon up predtest.c's powers to conclude from the default > partition's partition constraint that it cannot contain any keys < 1, but > then we'll have to frame up a clause expression describing the latter. > Generating such a clause expression can be a bit daunting for a > multi-column key. So, I haven't yet tried really hard to implement this. > Any thoughts on that?
I don't think we really want to get into theorem-proving here, because it's slow. Whatever we're going to do we should be able to do without that - keeping it in the form of btree-strategy + value. It doesn't seem that hard. Suppose we're asked to select partitions from tprt subject to (<, 10000). Well, we determine that some of the tprt_1 partitions may be relevant, so we tell tprt_1 to select partitions subject to (>=, 1, <, 10000). We know to do that because we know that 10000 < 50000 and we know to include >= 1 because we haven't got any lower bound currently at all. What's the problem? In some sense it's tempting to say that this case just doesn't matter very much; after all, subpartitioning on the same column used to partition at the top level is arguably lame. But if we can get it right in a relatively straightforward manner then let's do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers