From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [Proposal] Fully WAL logged CREATE DATABASE - No Checkpoints |
Date: | 2022-02-14 05:01:17 |
Message-ID: | CAFiTN-tjLjwDQOm_jH+7SA5=PqyKpS7eqN1LedJ2SD7VSOWB_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 13, 2022 at 9:56 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sun, Feb 13, 2022 at 1:34 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrot>
> > test4:
> > 32 GB shared buffers, template DB size = 10GB, dirty shared buffer=70%
> > Head: 47656 ms
> > Patch: 79767 ms
>
> This seems like the most surprising result of the bunch. Here, the
> template DB is both small enough to fit in shared_buffers and small
> enough not to trigger a checkpoint all by itself, and yet the patch
> loses.
Well this is not really surprising to me because what I have noticed
is that with the new approach the createdb time is completely
dependent upon the template db size. So if the source db size is 10GB
it is taking around 80sec and the shared buffers size does not have a
major impact. Maybe a very small shared buffer can have more impact
so I will test that as well.
>
> Did you checkpoint between one test and the next, or might this test
> have been done after a bunch of WAL had already been written since the
> last checkpoint so that the 10GB pushed it over the edge?
Not really, I am running each test with a new initdb so that could
not be an issue.
> BTW, you have test4 twice in your list of results.
My bad, those are different tests.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-02-14 05:11:37 | Re: pgsql: Add TAP test to automate the equivalent of check_guc |
Previous Message | Thomas Munro | 2022-02-14 04:15:05 | Re: Add client connection check during the execution of the query |