| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> |
| Cc: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kirill Reshke <reshke(at)double(dot)cloud>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Use fadvise in wal replay |
| Date: | 2022-07-18 19:55:59 |
| Message-ID: | CA+TgmoYNirSJ5cLNzYa-QRfkoGcKJx949DGi=XDSTvvjFXHDbw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 23, 2022 at 5:49 AM Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com> wrote:
> Cool. As for GUC I'm afraid there's going to be resistance of adding yet another GUC (to avoid many knobs). Ideally it would be nice if we had some advanced/deep/hidden parameters , but there isn't such thing.
> Maybe another option would be to use (N * maintenance_io_concurrency * XLOG_BLCKSZ), so N=1 that's 80kB and N=2 160kB (pretty close to default value, and still can be tweaked by enduser). Let's wait what others say?
I don't think adding more parameters is a problem intrinsically. A
good question to ask, though, is how the user is supposed to know what
value they should configure. If we don't have any idea what value is
likely to be optimal, odds are users won't either.
It's not very clear to me that we have any kind of agreement on what
the basic approach should be here, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-07-18 19:56:18 | pgsql: Move snowball_create.sql creation into perl file |
| Previous Message | David G. Johnston | 2022-07-18 19:55:48 | Re: BUG #17434: CREATE/DROP DATABASE can be executed in the same transaction with other commands |