Re: enable_joinremoval
От | Robert Haas |
---|---|
Тема | Re: enable_joinremoval |
Дата | |
Msg-id | 603c8f071003290832u23130f2x84ffa459e312269c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: enable_joinremoval (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: enable_joinremoval
|
Список | pgsql-hackers |
On Mon, Mar 29, 2010 at 11:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления: