Robert Haas wrote:
> 2011/2/23 PostgreSQL - Hans-J?rgen Sch?nig <>:
> > i thought there was an agreement that we don't want planner hints?
> Well, I want them.  I think some other people do, too.  Whether those
> people are more numerous than than the people who don't want them, and
> how much that matters either way, is another question.  I don't want
> to have to use them very often, but I like to have an out when I get
> desperate.
> > as tom pointed out - many broken queries come out of some query generator 
> > where even the design to make the design is broken by design.
> > personally i like query generators as long as other people use them ... 
> > telling people that this is the wrong way to go is actually financing my 
> > holiday next week ... ;). ?in general - hibernate and stuff like that is a 
> > no-go.
> >
> > personally i like the type of planner hints oleg and teodor came up with - 
> > i think we should do more of those hooks they are using but hiding it in 
> > some syntax is not a good idea.
> > it does not change the query and it still gives a lot of room to toy 
> > around. it looks like a compromise.
> >
> > however, oleg's contrib module does not fix the core problem of cross 
> > column statistics because a hint is usually static but you want flexible 
> > selectivity.
> IIRC, what Teodor and Oleg did was a contrib module that excluded a
> certain index from consideration based on a GUC.  That to me is a
> little more hacky than just wiring the selectivity estimate.  You're
> going to need to set that just before each query that needs it, and
> reset it afterwards, so it's actually worse than just decorating the
> queries, IMHO.  Also, I haven't run into any actual problems in the
> field that would be solved by this approach, though I am sure others
> have.  IME, most bad query plans are caused by either incorrect
> estimates of selectivity, or wrongheaded notions about what's likely
> to be cached.  If we could find a way, automated or manual, of
> providing the planner some better information about the facts of life
> in those areas, I think we'd be way better off.  I'm open to ideas
> about what the best way to do that is.

For me the key is finding a way to get that information to the planner
so all queries can benefit, not just the queries we decorate.

  Bruce Momjian  <>

  + It's impossible for everything to be true. +

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to