| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: path toward faster partition pruning |
| Date: | 2017-10-02 11:58:16 |
| Message-ID: | CA+TgmoY3gV7=GQf3EcfYZ_ZMwvmg2ek8s4LiSk8tWc4_6L+2fw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 1, 2017 at 9:13 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> 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.
What you might do is pass <btree-strategy-number, bounds> and
optionally allow a second <btree-strategy-number, bounds>. Then for
the common case of equality you can pass BTEqualStrategyNumber and for
a range bounded at both ends you can pass BTGreaterStrategyNumber or
BTGreaterEqualStrategyNumber for one bound and BTLessStrategyNumber or
BTLessEqualStrategyNumber for the other.
Not sure if this is exactly the right idea but it's what pops to mind.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2017-10-02 12:09:13 | Re: [PATCH] Assert that the correct locks are held when calling PageGetLSN() |
| Previous Message | Daniel Gustafsson | 2017-10-02 11:51:55 | Re: generated columns |