RE: [Patch] Optimize dropping of relation buffers using dlist

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: [Patch] Optimize dropping of relation buffers using dlist
Дата
Msg-id TYAPR01MB2990FAB85E317EBEF3684C8BFE300@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [Patch] Optimize dropping of relation buffers using dlist  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы RE: [Patch] Optimize dropping of relation buffers using dlist  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
Список pgsql-hackers
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> I thought that the advantage of this optimization is that we don't
> need to visit all buffers?  If we need to run a full-scan for any
> reason, there's no point in looking-up already-visited buffers
> again. That's just wastefull cycles.  Am I missing somethig?
>
> I don't understand. If we chose to the optimized dropping, the reason
> is the number of buffer lookup is fewer than a certain threashold. Why
> do you think that the fork kind a buffer belongs to is relevant to the
> criteria?

I rethought about this, and you certainly have a point, but...  OK, I think I understood.  I should have thought in a
complicatedway.  In other words, you're suggesting "Let's simply treat all forks as one relation to determine whether
tooptimize," right?  That is, the code simple becomes: 

Sums up the number of buffers to invalidate in all forks;
if (the cached sizes of all forks are valid && # of buffers to invalidate < THRESHOLD)
{
    do the optimized way;
    return;
}
do the traditional way;

This will be simple, and I'm +1.


Regards
Takayuki Tsunakawa






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

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Matthieu Garrigues
Дата:
Сообщение: Re: PATCH: Batch/pipelining support for libpq