Re: Improving replay of XLOG_BTREE_VACUUM records

Поиск
Список
Период
Сортировка
От Vladimir Borodin
Тема Re: Improving replay of XLOG_BTREE_VACUUM records
Дата
Msg-id D3139BC4-7EB3-4637-8E13-CB1B3015E674@simply.name
обсуждение исходный текст
Ответ на Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers

25 авг. 2015 г., в 16:03, Michael Paquier <michael.paquier@gmail.com> написал(а):

On Sun, Jul 26, 2015 at 9:46 PM, Andres Freund wrote:
On 2015-07-24 09:53:49 +0300, Heikki Linnakangas wrote:
To me it sounds like this shouldn't go through the full ReadBuffer()
rigamarole. That code is already complex enough, and here it's really
not needed. I think it'll be much easier to review - and actually faster
in many cases to simply have something like

bool
BufferInCache(Relation, ForkNumber, BlockNumber)
{
   /* XXX: setup tag, hash, partition */

   LWLockAcquire(newPartitionLock, LW_SHARED);
   buf_id = BufTableLookup(&newTag, newHash);
   LWLockRelease(newPartitionLock);
   return buf_id != -1;
}

and then fall back to the normal ReadBuffer() when it's in cache.

Yep, sounds good. Patch with implementation attached.


Patch marked as returned with feedback as input from the author has
been waited for some time now.

Sorry for delay, I will link it to the current commitfest.


--
Michael


--
May the force be with you…

Вложения

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: src/test/ssl broken on HEAD
Следующее
От: Robert Haas
Дата:
Сообщение: Re: exposing pg_controldata and pg_config as functions