| From: | Jacob Champion <jchampion(at)timescale(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] pg_dump: lock tables in batches |
| Date: | 2022-12-07 23:13:43 |
| Message-ID: | CAAWbhmj==58mmuU+H6jzCS3jcfSk_QGKAJZadPi5uPEi-gLv1w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 7, 2022 at 2:53 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Is "-s" mode actually a relevant criterion here? With per-table COPY
> commands added into the mix you could not possibly get better than 2x
> improvement, and likely a good deal less.
Don't we hit this code path in pg_upgrade? You won't see huge
round-trip times, of course, but you also won't see COPY.
Absolute performance aside, isn't there another concern that, the
longer it takes for us to lock the tables, the bigger the window there
is for someone to interfere with them between our catalog query and
the lock itself?
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Chudnovsky | 2022-12-07 23:22:51 | Re: [PoC] Federated Authn/z with OAUTHBEARER |
| Previous Message | Tom Lane | 2022-12-07 22:56:20 | Re: Error-safe user functions |