Re: get_loop_count() fails to ignore RELOPT_DEADREL rels
| От | David Rowley |
|---|---|
| Тема | Re: get_loop_count() fails to ignore RELOPT_DEADREL rels |
| Дата | |
| Msg-id | CAApHDvo5wCRk7uHBuMHJaDpbW-b_oGKQOuisCZzHC25=H3__fA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: get_loop_count() fails to ignore RELOPT_DEADREL rels (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: get_loop_count() fails to ignore RELOPT_DEADREL rels
|
| Список | pgsql-hackers |
On Sun, Jul 27, 2014 at 2:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Rowley <dgrowleyml@gmail.com> writes:That patch is entirely bogus. What you should be asking is why
> In order to get my patch working with an Assert enabled build I've had to
> apply the attached patch.
get_loop_count is being applied to a relation that's supposedly been
removed from the query. It should only get applied to rels that are
required outer rels for a parameterized path, and thus certainly
not dead.
hmm ok. After further investigation it seems that this is down to the EquivalenceClass still containing references to the dead rel. What seems to be happening is match_eclass_clauses_to_index() is calling generate_implied_equalities_for_column() which is generating RestrictInfo clauses which make reference to the dead relation.
With the existing left join removal code, in all the test cases I've thrown at it, match_eclass_clauses_to_index() seems to early exit on if (!index->rel->has_eclass_joins), but this is not the case when I'm removing SEMI and ANTI joins. So likely this is something I'll have to tackle in that patch, perhaps by stripping out the equivalence class members which belong to the newly dead rel in remove_rel_from_query().
Apologies for the noise
Regards
David Rowley
В списке pgsql-hackers по дате отправления: