Re: Path question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Path question
Дата
Msg-id 27256.1285362301@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Path question  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Path question  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> FIXME #1 and FIXME #2 were much harder to trigger.  In fact, barring
> significant further lobotimization of the code, I couldn't.

It's not that hard if you just tweak equivclass.c to make the order of
equivalence-class lists different, viz

diff --git a/src/backend/optimizer/path/equivclass.c b/src/backend/optimizer/path/equivclass.c
index a20ed5f..9528d0b 100644
--- a/src/backend/optimizer/path/equivclass.c
+++ b/src/backend/optimizer/path/equivclass.c
@@ -353,7 +353,7 @@ add_eq_member(EquivalenceClass *ec, Expr *expr, Relids relids,    {        ec->ec_relids =
bms_add_members(ec->ec_relids,relids);    }
 
-    ec->ec_members = lappend(ec->ec_members, em);
+    ec->ec_members = lcons(em, ec->ec_members);    return em;}


Then for instance:

regression=# create table t1 (f1 int); 
CREATE TABLE
regression=# create table t2 () inherits (t1);
CREATE TABLE
regression=# explain select * from t1 a join t1 b using (f1);
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1
WARNING:  FIXME #1

Since the order of equivalence-class member lists isn't supposed to be
semantically significant, I claim that the code in createplan has to
be able to deal with this.

Note that what this is triggering is the em_is_child condition.  I think
it may indeed be impossible to get a hit on the em_is_const case as the
system currently stands; the reason being that an EC containing a const
won't normally show up as a pathkey.  It can only do so if it's
below_outer_join, as the comment notes.  Now the calls to
make_sort_from_pathkeys in createplan.c are only used for constructing
subsidiary sorts for a mergejoin, and we won't consider building a
mergejoin with an EC that contains a const (see
eclass_useful_for_merging).  There are some calls in planner.c that are
associated with doing a final sort or distinct, but I suspect they'd
never be applied with a below_outer_join EC.  So given the current usage
of make_sort_from_pathkeys it might be pretty hard to get it applied to
an EC containing a constant.  That's not a reason for it not to handle
the case, though.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Review: Row-level Locks & SERIALIZABLE transactions, postgres vs. Oracle