Re: Pushing down sorted joins
От | Ashutosh Bapat |
---|---|
Тема | Re: Pushing down sorted joins |
Дата | |
Msg-id | CAFjFpRfLeZJG0XfZs44kYzQ8eG-YsUaTRaGgV6nS+XnAhfAFAw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Pushing down sorted joins (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Pushing down sorted joins
|
Список | pgsql-hackers |
This patch needs to be rebased.
Done.
+ /*
+ * 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.
Right. Removed the TODO
- if (bms_equal(em->em_relids, rel->relids))
+ if (bms_is_subset(em->em_relids, rel->relids))
Why do we need this?
The function find_em_expr_for_rel() find an equivalence member expression that has all its Vars come from the given relation. It's not necessary that it will have Vars from relids that are covered by the given relations. E.g. in query SELECT A.c1, B.c2 FROM A join B ON ... ORDER BY A.c3, there will be a single equivalence member A.c3 in the pathkeys and em_relids will indicate only A. Hence instead of equal, (which used to be OK for single relation join push-down) we have to use subset operation. We want an equivalence members whose relids are subset of relids contained by given relation.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Вложения
В списке pgsql-hackers по дате отправления: