Le 08/12/2022 à 01:03, Tom Lane a écrit :
Andres Freund <and...@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
