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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2011-02-23 22:48:38 Re: Review: Fix snapshot taking inconsistencies
Previous Message Tom Lane 2011-02-23 22:39:23 Re: Review: Fix snapshot taking inconsistencies