On Mon, Oct 12, 2009 at 11:31:24AM -0400, Robert Haas wrote:
> 2009/10/12 Teodor Sigaev <teodor@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.
A contrib module would certainly help test that idea, at least as far
as any knobs it provides.
> 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.
Nathan Boley (cc'd) has proposed smartening it up by figuring out what
class of distributions the table looks like it belongs to and acting
on that. Unsure how far this got as far as code, but I suspect Nathan
can address this :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate