Re: WIP: cross column correlation ...

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: WIP: cross column correlation ...
Дата
Msg-id 201102232240.p1NMe0x19604@momjian.us
обсуждение исходный текст
Ответ на Re: WIP: cross column correlation ...  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas wrote:
> 2011/2/23 PostgreSQL - Hans-J?rgen Sch?nig <postgres@cybertec.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
isbroken by design.
 
> > personally i like query generators as long as other people use them ... telling people that this is the wrong way
togo 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
theyare 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
staticbut 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: WIP: cross column correlation ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Review: Fix snapshot taking inconsistencies