Re: enable_joinremoval

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: enable_joinremoval
Дата
Msg-id 603c8f071003290637q14d431f7j90afabd6fd2ec952@mail.gmail.com
обсуждение исходный текст
Ответ на enable_joinremoval  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: enable_joinremoval
Re: enable_joinremoval
Список pgsql-hackers
On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> We have planner method parameters for many important parts of the
> planner. We don't have any parameter for join removal, AFAIK.
>
> The first question I get asked is "can I see the tables it removed?".
> This has been asked of me 3 times now this year, always first question.
> Same issue applies to constraint exclusion.
>
> But we *can* do this with constraint_exclusion, simply by turning it off
> and checking the two outputs.
>
> So I think we need a parameter for join removal also.
>
> I don't want to turn it off, but I think we need a way for people to
> check themselves that the removal of the joins is not an error. I
> foresee many false bug reports along the lines of "optimizer ate my join
> and I want it back".

I had this in my original patch but Tom wanted it taken out.  In many
cases it's not horribly difficult to work around because you can do
SELECT * FROM ... instead of your original select list, but there
might be some cases with multiple levels of views where it isn't that
easy.  I think it would be good to add this back.

An even worse problem I've been noticing is that there is no easy way
to determine whether the planner's new penchant for inserting
Materialize notes in all sorts of fun and exciting places is in fact
improving performance or not.  I'm not sure there's even a difficult
way.  I really, really think we need to do something out this - the
current situation is really quite horrible.

...Robert


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

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: Problems with variable cursorname in ecpg
Следующее
От: Robert Haas
Дата:
Сообщение: Re: five-key syscaches