Re: anti-join chosen even when slower than old plan

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: anti-join chosen even when slower than old plan
Дата
Msg-id AANLkTikJWuGy2ejHSFygF-HTzkOewefLx=ewDL1V2B-o@mail.gmail.com
обсуждение исходный текст
Ответ на Re: anti-join chosen even when slower than old plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
On Fri, Nov 12, 2010 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think his point is that we already have a proven formula
> (Mackert-Lohmann) and shouldn't be inventing a new one out of thin air.
> The problem is to figure out what numbers to apply the M-L formula to.

I'm not sure that's really measuring the same thing, although I'm not
opposed to using it if it produces reasonable answers.

> I've been thinking that we ought to try to use it in the context of the
> query as a whole rather than for individual table scans; the current
> usage already has some of that flavor but we haven't taken it to the
> logical conclusion.

That's got a pretty severe chicken-and-egg problem though, doesn't it?
 You're going to need to know how much data you're touching to
estimate the costs so you can pick the best plan, but you can't know
how much data will ultimately be touched until you've got the whole
plan.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: MVCC performance issue
Следующее
От: Robert Haas
Дата:
Сообщение: Re: questions regarding shared_buffers behavior