enable_joinremoval
in [PgSql]
|
From: Jaime Casanova on 29 Mar 2010 11:23 On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera <alvherre(a)commandprompt.com> wrote: > > It seems that what's really needed is some debug output to be able to > find out what it did. > > +1, i was preparing an env for testing this but in the while i was thinking how can i know what happens... counting the tables in the explain analyze? it's possible but not ideal -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 29 Mar 2010 11:27 Robert Haas <robertmhaas(a)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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Mar 2010 11:29 On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova <jcasanov(a)systemguards.com.ec> wrote: > On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera > <alvherre(a)commandprompt.com> wrote: >> >> It seems that what's really needed is some debug output to be able to >> find out what it did. > > +1, i was preparing an env for testing this but in the while i was > thinking how can i know what happens... counting the tables in the > explain analyze? it's possible but not ideal I don't actually see much value in making EXPLAIN show which tables were removed. The usefulness of doing that presumes that the user is asking a particular and very specific question, namely, exactly which tables got removed?, or perhaps, did this particular table get removed? The latter question is not too hard to figure out anyway - just look for that table in the query. The former is a little harder but if you really need to know you can always look at which tables WERE referenced and work backwards from there, or write a little script to post-process the JSON, XML, or YAML output. Of course sometimes it would be handy to have but if we start adding too many bells and whistles to the EXPLAIN output it will get cluttered and unuseful. I think the value of an enable_joinremoval switch is that it lets someone throw the switch and see how the plan changes. It might change in a very simple way or it might have a dramatic effect on the whole plan. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 29 Mar 2010 11:32 On Mon, Mar 29, 2010 at 11:27 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jaime Casanova on 29 Mar 2010 11:42
On Mon, Mar 29, 2010 at 11:29 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Mon, Mar 29, 2010 at 11:23 AM, Jaime Casanova > <jcasanov(a)systemguards.com.ec> wrote: >> On Mon, Mar 29, 2010 at 10:42 AM, Alvaro Herrera >> <alvherre(a)commandprompt.com> wrote: >>> >>> It seems that what's really needed is some debug output to be able to >>> find out what it did. >> >> +1, i was preparing an env for testing this but in the while i was >> thinking how can i know what happens... counting the tables in the >> explain analyze? it's possible but not ideal > > I don't actually see much value in making EXPLAIN show which tables > were removed. no, i was thinking in something like a DEBUG message indicating that that rel is being removed... maybe a DEBUG1 message -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL AsesorÃa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |