Re: path toward faster partition pruning

On Thu, Oct 26, 2017 at 1:17 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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