Skip site navigation (1) Skip section navigation (2)

Re: enable_joinremoval

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: enable_joinremoval
Date: 2010-03-29 13:37:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Mar 29, 2010 at 4:33 AM, Simon Riggs <simon(at)2ndquadrant(dot)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.


In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2010-03-29 13:39:22
Subject: Re: five-key syscaches
Previous:From: Boszormenyi ZoltanDate: 2010-03-29 13:35:42
Subject: Re: Problems with variable cursorname in ecpg

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group