| From: | Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> |
|---|---|
| To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
| Cc: | Maxim Orlov <m(dot)orlov(at)postgrespro(dot)ru>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Pre-allocating WAL files |
| Date: | 2021-12-30 11:45:42 |
| Message-ID: | CALT9ZEG+R9ne6xTyEVSiLhZ7wJAQ1Jq-9XVZs=zbd_jQJyPTdA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>
> > pre-allocating during checkpoints. I've done a few pgbench runs, and
> > it seems to work pretty well. Initialization is around 15% faster,
> > and I'm seeing about a 5% increase in TPS with a simple-update
> > workload with wal_recycle turned off. Of course, these improvements
> > go away once segments can be recycled.
>
I've checked the patch v7. It applies cleanly, code is good, check-world
tests passed without problems.
I think it's ok to use checkpointer for this and the overall patch can be
committed. But the seen performance gain makes me think again before adding
this feature. I did tests myself a couple of months ago and got similar
results.
Really don't know whether is it worth the effort.
Wish you and all hackers happy New Year!
--
Best regards,
Pavel Borisov
Postgres Professional: http://postgrespro.com <http://www.postgrespro.com>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Maxim Orlov | 2021-12-30 11:51:10 | Re: Pre-allocating WAL files |
| Previous Message | Yura Sokolov | 2021-12-30 11:14:32 | Fix BUG #17335: Duplicate result rows in Gather node |