From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: enable_joinremoval |
Date: | 2010-03-29 15:32:04 |
Message-ID: | 603c8f071003290832u23130f2x84ffa459e312269c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 29, 2010 at 11:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> And for the record, I believe I find it rather amusing that you're
>> asking me if I "have the faintest idea how many there would be".
>
> Actually that was directed more at Simon.
>
>> I venture to say that after yourself I might be the person who knows
>> this code best. I know how many there will be, if I get my way, and
>> that number is two.
>
> If you're speaking of adding a switch for the materialize-insertion
> behavior, I didn't object to that; I agree that turning that off might
> be an interesting thing to do. But I remain of the opinion that a
> switch to disable join removal is just useless code and user-visible
> complexity.
OK, I'll write a patch for that; and a consensus emerges that we
should also have enable_joinremoval, then I will add that as well. I
think the only argument for NOT having enable_joinremoval is that you
can always modify the query to say SELECT * rather than some more
specific SELECT list, but I think when there are several levels of
views involved it may not be so simple - you'll have to define
temporary versions of all the intermediate views, which is possibly
somewhat painful and certainly error-prone.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-03-29 15:40:26 | Re: Parallel pg_dump for 9.1 |
Previous Message | Robert Haas | 2010-03-29 15:29:25 | Re: enable_joinremoval |