Re: Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints

From: David Fetter <david(at)fetter(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Bruce Momjian <bruce(at)momjian(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nathan Boley <npboley(at)gmail(dot)com>
Subject: Re: Re: [GENERAL] contrib/plantuner - enable PostgreSQL planner hints
Date: 2009-10-12 16:45:26
Message-ID: 20091012164525.GG14810@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Mon, Oct 12, 2009 at 11:31:24AM -0400, Robert Haas wrote:
> 2009/10/12 Teodor Sigaev <teodor(at)sigaev(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Erik Jones 2009-10-12 17:36:15 Re: Is there a way to know if trigger is invoked by the code from another trigger
Previous Message Ivan Sergio Borgonovo 2009-10-12 16:37:40 setweight detailed doc was: Ranking search results using multiple fields in PostgreSQL fulltext search

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-10-12 17:59:30 Re: Is FOR UPDATE an optimization fence?
Previous Message Tom Lane 2009-10-12 15:42:08 EvalPlanQual seems a tad broken