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

Поиск
Список
Период
Сортировка
От Cédric Villemain
Тема Re: anti-join chosen even when slower than old plan
Дата
Msg-id AANLkTimsVhtzesHRc_V+wk2E6j_fow3A5yrmWr4qeWBv@mail.gmail.com
обсуждение исходный текст
Ответ на Re: anti-join chosen even when slower than old plan  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: anti-join chosen even when slower than old plan  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-performance
2011/1/19 Bruce Momjian <bruce@momjian.us>:
> Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>> > On Fri, Nov 12, 2010 at 4:15 AM, Cédric Villemain
>> > <cedric.villemain.debian@gmail.com> wrote:
>> >>> I wondering if we could do something with a formula like 3 *
>> >>> amount_of_data_to_read / (3 * amount_of_data_to_read +
>> >>> effective_cache_size) = percentage NOT cached.  That is, if we're
>> >>> reading an amount of data equal to effective_cache_size, we assume 25%
>> >>> caching, and plot a smooth curve through that point.  In the examples
>> >>> above, we would assume that a 150MB read is 87% cached, a 1GB read is
>> >>> 50% cached, and a 3GB read is 25% cached.
>>
>> >> But isn't it already the behavior of effective_cache_size usage ?
>>
>> > No.
>>
>> 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'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.
>
> Is there a TODO here?

it looks like, yes.

>
> --
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>  + It's impossible for everything to be true. +
>



--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

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

Предыдущее
От: Achilleas Mantzios
Дата:
Сообщение: Re: "NOT IN" substantially slower in 9.0.2 than 8.3.13 - NOT EXISTS runs fast in both 8.3.13 and 9.0.2
Следующее
От: Robert Haas
Дата:
Сообщение: Re: anti-join chosen even when slower than old plan