Re: Getting query plan alternatives from query planner?

От: Tom Lane
Тема: Re: Getting query plan alternatives from query planner?
Дата: ,
Msg-id: 15606.1395335330@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Getting query plan alternatives from query planner?  (Stefan Keller)
Ответы: Re: Getting query plan alternatives from query planner?  (Stefan Keller)
Список: pgsql-performance

Скрыть дерево обсуждения

Getting query plan alternatives from query planner?  (Stefan Keller, )
 Re: Getting query plan alternatives from query planner?  (Tom Lane, )
  Re: Getting query plan alternatives from query planner?  (Stefan Keller, )
   Re: Getting query plan alternatives from query planner?  (Atri Sharma, )
    Re: Getting query plan alternatives from query planner?  (Craig James, )
     Re: Getting query plan alternatives from query planner?  (Tom Lane, )
     Re: Getting query plan alternatives from query planner?  (Shaun Thomas, )
      Re: Getting query plan alternatives from query planner?  (Kevin Grittner, )
       Re: Getting query plan alternatives from query planner?  (Eric Schwarzenbach, )
 Re: Getting query plan alternatives from query planner?  (Craig James, )
  Re: Getting query plan alternatives from query planner?  (Stefan Keller, )
   Re: Getting query plan alternatives from query planner?  (Heikki Linnakangas, )

Stefan Keller <> writes:
> I'd like to know from the query planner which query plan alternatives
> have been generated and rejected. Is this possible?

No, not really.  People have occasionally hacked the planner to print
rejected paths before they're discarded, but there's no convenient way
to do anything except send the data to the postmaster log, which isn't
all that convenient.  A bigger problem is that people who are asking
for this typically imagine that the planner generates complete plans
before rejecting them; which it does not.  Path alternatives are rejected
whenever possible before moving up to the next join level, so that what
we have rejected is actually just a plan fragment in most cases.

            regards, tom lane



В списке pgsql-performance по дате сообщения:

От: Torsten Förtsch
Дата:
Сообщение: Re: Performance of UNION vs IN
От: Stefan Amshey
Дата:
Сообщение: slow join not using index properly