Re: Improving replay of XLOG_BTREE_VACUUM records - Mailing list pgsql-hackers

From Vladimir Borodin
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id D3139BC4-7EB3-4637-8E13-CB1B3015E674@simply.name
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records  (Michael Paquier <michael.paquier@gmail.com>)
List 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…

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: src/test/ssl broken on HEAD
Next
From: Robert Haas
Date:
Subject: Re: exposing pg_controldata and pg_config as functions