> On Fri, Oct 09, 2020 at 11:08:42PM +0500, Andrey Borodin wrote:
>
> > 23 сент. 2020 г., в 23:19, Peter Geoghegan <pg@bowt.ie> написал(а):
> >
> > On Fri, Sep 18, 2020 at 8:39 AM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
> >> Here is PoC with porting that same routine to B-tree. It allows to build B-trees ~10% faster on my machine.
> >
> > It doesn't seem to make any difference on my machine, which has an
> > NVME SSD (a Samsung 970 Pro). This is quite a fast SSD, though the
> > sync time isn't exceptional. My test case is "reindex index
> > pgbench_accounts_pkey", with pgbench scale 500. I thought that this
> > would be a sympathetic case, since it's bottlenecked on writing the
> > index, with relatively little time spent scanning and sorting in
> > parallel workers.
> > Can you provide a test case that is sympathetic towards the patch?
> Thanks for looking into this!
>
> I've tried this test on my machine (2019 macbook) on scale 10 for 20 seconds.
> With patch I get consistently ~ tps = 2.403440, without patch ~ tps = 1.951975.
> On scale 500 with patch
> postgres=# reindex index pgbench_accounts_pkey;
> REINDEX
> Time: 21577,640 ms (00:21,578)
> without patch
> postgres=# reindex index pgbench_accounts_pkey;
> REINDEX
> Time: 26139,175 ms (00:26,139)
>
> I think it's hardware dependent, I will try on servers.
Hi,
Thanks for the patch! Out of curiosity I've tried to experiment with it,
and in the reindex scenario Peter mentioned above I also can't see any
visible difference. Interesting enough, _bt_blwritepage tracing (IIUC
after reading the patch it's the main target) shows the influence of
batching, but apparently in my case it hits some other bottleneck (e.g.
profiling shows increase in LockBuffer and LogicalTapeRead).
