2009/10/12 Teodor Sigaev <teo...@sigaev.ru>: >> Are you planning to submit this as a /contrib module? > > I haven't objections to do that, we don't planned that because we know > sceptical > relation of community to hints :)
I think it would be pretty useful to have some additional knobs to poke at the planner. I sometimes want to know what the planner thinks the cost of some plan other than the one actually selected would be. For simple queries, it's often possible to accomplish this by using the enable_* parameters, but those are a pretty coarse instrument and what you can do with them is fairly limited. So I think it would be nice to have some more options, and I wouldn't object to including this as one of them, provided that the code isn't too much of a kludge. That having been said, my tables don't tend to be heavily indexed and the planner basically never picks the wrong one. Most of my query planning problems (and many of the ones on -performance) are the result of bad selectivity estimates. So what I'd really like to see is a way to override the selectivity of a given expression. Making the planner smarter about estimating selectivity in the first place would be *great*, too, but I don't have much hope that it's ever going to be perfect. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
