Re: [PATCH] pg_dump: lock tables in batches - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] pg_dump: lock tables in batches
Date
Msg-id 12690.1670457780@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] pg_dump: lock tables in batches  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] pg_dump: lock tables in batches  (Gilles Darold <gilles@migops.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-12-07 17:53:05 -0500, Tom Lane 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.

> Well, -s isn't something used all that rarely, so it'd not be insane to
> optimize it in isolation. But more importantly, I think the potential win
> without -s is far bigger than 2x, because the COPYs can be done in parallel,
> whereas the locking happens in the non-parallel stage.

True, and there's the reduce-the-lock-window issue that Jacob mentioned.

> With just a 5ms delay, very well within normal network latency range, I get:
> [ a nice win ]

OK.  I'm struggling to figure out why I rejected this idea last year.
I know that I thought about it and I'm fairly certain I actually
tested it.  Maybe I only tried it with near-zero-latency local
loopback; but I doubt that, because the potential for network
latency was certainly a factor in that whole discussion.

One idea is that I might've tried it before getting rid of all the
other per-object queries, at which point it wouldn't have stood out
quite so much.  But I'm just guessing.  I have a nagging feeling
there was something else.

Oh well, I guess we can always revert it if we discover a problem later.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Error-safe user functions
Next
From: Justin Pryzby
Date:
Subject: Re: fix and document CLUSTER privileges