Re: Boundary value check in lazy_tid_reaped()

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Boundary value check in lazy_tid_reaped()
Date: 2021-03-09 00:57:31
Message-ID: CAD21AoDuO8ZpSQw2DN_J-3tP+DYcKsXk3FwUAhhQy3c6bNUZWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 8, 2021 at 7:16 PM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>
> On 21.01.21 14:11, Masahiko Sawada wrote:
> > Agreed. bsearch with bound check showed a reasonable improvement in my
> > evaluation in terms of performance. Regarding memory efficiency, we
> > can experiment with other methods later.
> >
> > I've attached the patch that adds a bound check for encoded
> > itermpointers before bsearch() in lazy_tid_reaped() and inlines the
> > function.
>
> Do you have any data showing the effect of inlining lazy_tid_reaped()?
> I mean, it probably won't hurt, but it wasn't part of the original patch
> that you tested, so I wonder whether it has any noticeable effect.

I've done some benchmarks while changing the distribution of where
dead tuples exist within the table. The table size is 4GB and 20% of
total tuples are dirty. Here are the results of index vacuum execution
time:

1. Updated evenly the table (every block has at least one dead tuple).
master : 8.15
inlining : 4.84
not-inlinning : 5.01

2. Updated the middle of the table.
master : 8.71
inlining : 3.51
not-inlinning : 3.58

3. Updated both the beginning and the tail of the table.
master : 8.44
inlining : 3.46
not-inlinning : 3.50

There is no noticeable effect of inlining lazy_tid_reaped(). So it
would be better to not do that.

Regards,

--
Masahiko Sawada
EDB: https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-03-09 01:28:43 Re: cleanup temporary files after crash
Previous Message Jacob Champion 2021-03-09 00:48:20 Re: Proposal: Save user's original authenticated identity for logging