From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pushing down sorted joins |
Date: | 2016-03-08 19:26:24 |
Message-ID: | CA+TgmoYGJgZVscSY_UiJ9=NoMnQ6Qeu-XxaMy0=SvneAXo==SA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 23, 2016 at 7:48 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> Rushabh pointed out that declarations of helper functions
> get_useful_ecs_for_relation and get_useful_pathkeys_for_relation() are part
> of FDW routines declarations rather than helper function declaration. Since
> those functions are related to this patch, the attached patch moves those
> declaration in their right place.
This patch needs to be rebased.
+ /*
+ * TODO: we should worry about EPQ path but should
that path have
+ * pathkeys? I guess, that's not really important
since it's just
+ * going to evaluate the join from whole-row
references stuffed in the
+ * corresponding EPQ slots, for which the order doesn't matter.
+ */
The pathkeys for the EPQ path don't matter. It'll only be called to
recheck one single row, and there's only one order in which you can
return one row.
- if (bms_equal(em->em_relids, rel->relids))
+ if (bms_is_subset(em->em_relids, rel->relids))
Why do we need this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-08 19:36:01 | Re: Minor documentation tweak to GetForeignPlan documentation |
Previous Message | Alvaro Herrera | 2016-03-08 19:16:01 | Re: More stable query plans via more predictable column statistics |