From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Recovery performance of DROP DATABASE with many tablespaces |
Date: | 2018-07-04 16:42:20 |
Message-ID: | CAHGQGwHMcfDHfWFbOG=5Wopy-p7ABtOASCskuN7NemJ+ohADwA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 4, 2018 at 4:47 PM, Jamison, Kirk <k(dot)jamison(at)jp(dot)fujitsu(dot)com> wrote:
> Hi, Fujii-san
>
> I came across this post and I got interested in it,
> so I tried to apply/test the patch but I am not sure if I did it correctly.
> I set-up master-slave sync, 200GB shared_buffers, 20000 max_locks_per_transaction,
> 1 DB with 500 table partitions shared evenly across 5 tablespaces.
>
> After dropping the db, with or without patch,
> there were no difference in recovery performance when dropping database,
> so maybe I made a mistake somewhere. But anyway, here's the results.
>
> ======WITHOUT PATCH=======
> [200GB shared buffers]
> DROPDB only (skipped DROP TABLE and DROP TABLESPACE)
> 2018/07/04_13:35:00.161
> dropdb
> 2018/07/04_13:35:05.591 5.591 sec
>
> [200GB shared_buffers]
> DROPDB (including DROP TABLE and DROP TABLESPACE)
> real 3m19.717s
> user 0m0.001s
> sys 0m0.001s
>
> ======WITH PATCH=======
> [200GB shared_buffers]
> DROPDB only (skipped DROP TABLE and DROP TABLESPACE)
> 2018/07/04_14:19:47.128
> dropdb
> 2018/07/04_14:19:53.177 6.049 sec
>
> [200GB shared_buffers]
> DROPDB (included the DROP TABLE and DROP TABLESPACE commands)
> real 3m51.834s
> user 0m0.001s
> sys 0m0.002s
>
> Just in case, do you also have some performance test numbers/case
> to show the recovery perf improvement when dropping database that contain multiple tablespaces?
Thanks for testing!
TBH, I have no numbers measured by the test.
One question about your test is; how did you measure the *recovery time*
of DROP DATABASE? Since it's *recovery* performance, basically it's not easy
to measure that.
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-07-04 16:43:53 | Why B-Tree suffix truncation matters |
Previous Message | Sergei Kornilov | 2018-07-04 15:59:20 | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query |