Re: postgres_fdw: wrong results with self join + enable_nestloop off
| От | Richard Guo |
|---|---|
| Тема | Re: postgres_fdw: wrong results with self join + enable_nestloop off |
| Дата | |
| Msg-id | CAMbWs4-8huBA2ZzxMxYL85=c=LMnK7W95XD+XSeKwQmkXacQFg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: postgres_fdw: wrong results with self join + enable_nestloop off (Nishant Sharma <nishant.sharma@enterprisedb.com>) |
| Список | pgsql-hackers |
On Fri, Jun 2, 2023 at 8:31 PM Nishant Sharma <nishant.sharma@enterprisedb.com> wrote:
I only had a minor comment on below change:-- gating_clauses = get_gating_quals(root, scan_clauses);
+ if (best_path->pathtype == T_ForeignScan && IS_JOIN_REL(rel))
+ gating_clauses = get_gating_quals(root, ((ForeignPath *) best_path)->joinrestrictinfo);
+ else
+ gating_clauses = get_gating_quals(root, scan_clauses);Instead of using 'if' and creating a special case here can't we do something in the above switch?
I thought about that too. IIRC I did not do it in that way because
postgresGetForeignPlan expects that there is no scan_clauses for a join
rel. So doing that would trigger the Assert there.
/*
* For a join rel, baserestrictinfo is NIL and we are not considering
* parameterization right now, so there should be no scan_clauses for
* a joinrel or an upper rel either.
*/
Assert(!scan_clauses);
Thanks
Richard
postgresGetForeignPlan expects that there is no scan_clauses for a join
rel. So doing that would trigger the Assert there.
/*
* For a join rel, baserestrictinfo is NIL and we are not considering
* parameterization right now, so there should be no scan_clauses for
* a joinrel or an upper rel either.
*/
Assert(!scan_clauses);
Thanks
Richard
В списке pgsql-hackers по дате отправления: