Skip site navigation (1) Skip section navigation (2)

Re: WIP: cross column correlation ...

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>
Subject: Re: WIP: cross column correlation ...
Date: 2011-02-23 22:40:00
Message-ID: 201102232240.p1NMe0x19604@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Robert Haas wrote:
> 2011/2/23 PostgreSQL - Hans-J?rgen Sch?nig <postgres(at)cybertec(dot)at>:
> > 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  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

In response to

pgsql-hackers by date

Next:From: Marko TiikkajaDate: 2011-02-23 22:48:38
Subject: Re: Review: Fix snapshot taking inconsistencies
Previous:From: Tom LaneDate: 2011-02-23 22:39:23
Subject: Re: Review: Fix snapshot taking inconsistencies

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group