Re: Simple join optimized badly?

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Simple join optimized badly?
Дата
Msg-id 200610101028.30191.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: Simple join optimized badly?  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Simple join optimized badly?
Список pgsql-performance
Jim,

> We've depricated things before, I'm sure we'll do it again. Yes, it's a
> pain, but it's better than not having anything release after release.
> And having a formal hint language would at least allow us to eventually
> clean up some of these oddball cases, like the OFFSET 0 hack.
>
> I'm also not convinced that even supplimental statistics will be enough
> to ensure the planner always does the right thing, so query-level hints
> may have to stay (though it'd be great if that wasn't the case).

"stay"?   I don't think that the general developers of PostgreSQL are going
to *accept* anything that stands a significant chance of breaking in one
release.   You have you challange for the EDB development team: come up
with a hinting language which is flexible enough not to do more harm than
good (hint: it's not Oracle's hints).

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: long running transactions
Следующее
От: Tobias Brox
Дата:
Сообщение: Re: long running transactions