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

From Michael Paquier
Subject Re: Improving replay of XLOG_BTREE_VACUUM records
Date
Msg-id CAB7nPqQG5kFYDiLhcAeuDAKmHfheFzjEd+_Q-PE8sL1+zd-zUQ@mail.gmail.com
Whole thread Raw
In response to Re: Improving replay of XLOG_BTREE_VACUUM records  (Andres Freund <andres@anarazel.de>)
Responses Re: Improving replay of XLOG_BTREE_VACUUM records  (Vladimir Borodin <root@simply.name>)
List pgsql-hackers
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.

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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Can pg_dump make use of CURRENT/SESSION_USER
Next
From: Michael Paquier
Date:
Subject: Re: compress method for spgist - 2