Re: explain.c: why trace PlanState and Plan trees separately?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: explain.c: why trace PlanState and Plan trees separately?
Дата
Msg-id 27963.1279030203@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: explain.c: why trace PlanState and Plan trees separately?  (Yeb Havinga <yebhavinga@gmail.com>)
Ответы Re: explain.c: why trace PlanState and Plan trees separately?  (Yeb Havinga <yebhavinga@gmail.com>)
Список pgsql-hackers
Yeb Havinga <yebhavinga@gmail.com> writes:
> Tom Lane wrote:
>> The reason I'm on about this at the moment is that I think I see how to
>> get ruleutils to print PARAM_EXEC Params as the referenced expression
>> rather than $N ...

> Wouldn't this obfuscate the plan more than printing subplan arguments at 
> the call site?

It would if subplans could have more than one call site, but they can't.

I do intend to force qualification of Vars that are printed as a result
of param expansion; for example consider a standard nestloop-with-
inner-indexscan plan:
NestLoop    Seq Scan on a    Index Scan on b        Index Cond: x = a.y

If y weren't qualified to show that it's not a variable of b, this could
be confusing.  But as long as we do that, it pretty much matches our
historical behavior.  Note that CVS HEAD is printing this case as
NestLoop    Seq Scan on a    Index Scan on b        Index Cond: x = $0

which is definitely not very helpful.
        regards, tom lane


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: dblink regression failure in HEAD
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Last call for patches for the July CommitFest