On 17.06.2020 09:14, k.jamison@fujitsu.com wrote:
> Hi,
>
> Since the last posted version of the patch fails, attached is a rebased version.
> Written upthread were performance results and some benefits and challenges.
> I'd appreciate your feedback/comments.
>
> Regards,
> Kirk Jamison
As far as i understand this patch can provide significant improvement of
performance only in case of
recovery of truncates of large number of tables. You have added shared
hash of relation buffers and certainly if adds some
extra overhead. According to your latest results this overhead is quite
small. But it will be hard to prove that there will be no noticeable
regression
at some workloads.
I wonder if you have considered case of local hash (maintained only
during recovery)?
If there is after-crash recovery, then there will be no concurrent
access to shared buffers and this hash will be up-to-date.
in case of hot-standby replica we can use some simple invalidation (just
one flag or counter which indicates that buffer cache was updated).
This hash also can be constructed on demand when DropRelFileNodeBuffers
is called first time (so w have to scan all buffers once, but subsequent
drop operation will be fast.
i have not thought much about it, but it seems to me that as far as this
problem only affects recovery, we do not need shared hash for it.