| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Paul Guo <paulguo(at)gmail(dot)com> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Paul Guo <guopa(at)vmware(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Two patches to speed up pg_rewind. |
| Date: | 2021-08-18 00:43:49 |
| Message-ID: | YRxXdyWNfzwhHAP+@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 17, 2021 at 04:47:44PM +0900, Michael Paquier wrote:
> One argument
> against this approach is that if pg_rewind fails in the middle of its
> operation then we would have done a set of fsync() for nothing, with
> the data folder still unusable.
I was skimming through the patch this morning, and that argument does
not hold much water as the flushes happen in the same place. Seems
like I got confused, sorry about that.
> I would be curious to see some
> numbers to see how much it matters with many physical files (say cases
> with thousands of small relations?).
For this one, one simple idea would be to create a lot of fake
relation files with a pre-determined size and check how things
change.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2021-08-18 01:04:04 | Re: [PATCH]Remove obsolete macro CHECKFLOATVAL in btree_gist |
| Previous Message | Michael Paquier | 2021-08-18 00:32:37 | Re: Support for NSS as a libpq TLS backend |