Re: [PATCH] pg_dump: lock tables in batches

Le 08/12/2022 à 01:03, Tom Lane a écrit :
> 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
>
Hi,


I have done a review of this patch, it applies well on current master 
and compiles without problem.

make check/installcheck and world run without failure, pg_dump tests 
with pgtap enabled work fine too.

I have also given a try to the bench mentioned in the previous posts and 
I have the same performances gain with the -s option.


As it seems to have a consensus to apply this patch I will change the 
commitfest status to ready for committers.


Regards,

-- 
Gilles Darold