Re: Simple join optimized badly?

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Simple join optimized badly?
Дата
Msg-id 20061010140050.GZ72517@nasby.net
обсуждение исходный текст
Ответ на Re: Simple join optimized badly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Simple join optimized badly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Mon, Oct 09, 2006 at 06:45:16PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > One of the big problems with doing set enable_...=off is that there's no
> > way to embed that into something like a view, so you're almost forced
> > into putting into the application code itself, which makes matters even
> > worse. If you could hint this within a query (maybe even on a per-table
> > level), you could at least encapsulate that into a view.
>
> You've almost reinvented one of the points that was made in the last
> go-round on the subject of hints, which is that keeping them out of the
> application code is an important factor in making them manageable by a
> DBA.  Hints stored in a system catalog (and probably having the form of
> "make this statistical assumption" rather than specifically "use that
> plan") would avoid many of the negatives.

Sure, but IIRC no one's figured out what that would actually look like,
while it's not hard to come up with a syntax that allows you to tell the
optimizer "scan index XYZ to access this table". (And if there's real
interest in adding that I'll come up with a proposal.)

I'd rather have the ugly solution sooner rather than the elegant one
later (if ever).
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

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

Предыдущее
От: "Ravindran G - TLS, Chennai."
Дата:
Сообщение: Postgre 8.0 Installation - Issues
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Simple join optimized badly?