On 2017/09/30 1:28, Robert Haas wrote: > On Thu, Sep 28, 2017 at 5:16 AM, David Rowley > <david.row...@2ndquadrant.com> wrote: >> I'd imagine, for >> each partition key, you'd want to store a Datum with the minimum and >> maximum possible value based on the quals processed. If either the >> minimum or maximum is still set to NULL, then it's unbounded at that >> end. If you encounter partkey = Const, then minimum and maximum can be >> set to the value of that Const. From there you can likely ignore any >> other quals for that partition key, as if the query did contain >> another qual with partkey = SomeOtherConst, then that would have >> become a gating qual during the constant folding process. This way if >> the user had written WHERE partkey >= 1 AND partkey <= 1 the >> evaluation would end up the same as if they'd written WHERE partkey = >> 1 as the minimum and maximum would be the same value in both cases, >> and when those two values are the same then it would mean just one >> theoretical binary search on a partition range to find the correct >> partition instead of two. > > I have not looked at the code submitted here in detail yet but I do > think we should try to avoid wasting cycles in the > presumably-quite-common case where equality is being tested. The > whole idea of thinking of this as minimum/maximum seems like it might > be off precisely for that reason.
I agree. Equality checks are going to be common enough to warrant them to be handled specially, instead of implementing equality-pruning on top of min/max framework. 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
