Re: Improvements and additions to COPY progress reporting

On Tue, Mar 9, 2021 at 11:04 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > This is keeping current behaviour of the implementation as committed
> > with 8a4f618e, with the rationale of that patch being that this number
> > should mirror the number returned by the copy command.
> >
> > I am not opposed to adding another column for `tuples_inserted` and
> > changing the logic accordingly (see prototype 0003), but that was not
> > in the intended scope of this patchset. Unless you think that this
> > should be included in this current patchset, I'll spin that patch out
> > into a different thread, but I'm not sure that would make it into
> > pg14.
>
> Okay, point taken. If there is demand for it in the future, we could
> extend the existing set of columns. After thinking more about it the
> usecase if not completely clear to me from a monitoring point of
> view.

I think, for now, having better comments on what's included and what's
not in the existing tuples_processed column would help.

> I have not looked at 0002 in details yet, but I am wondering first if
> the size estimations in the expected output are actually portable.
> Second, I doubt a bit that the extra cycles spent on that are actually
> worth the coverage, even if the trick with an AFTER INSERT trigger is
> interesting.

I was having the same doubt [1], please have a look at it and the few
threads that follow. IMO, we can have the tests without the
"bytes_total" column if we think that it's not stable across all OS
platforms. I think those tests don't take much time to run and AFAIK
it's the first progress report command to have tests because others
such as analyse, vacuum, cluster, base backup don't have.

[1] - https://www.postgresql.org/message-id/flat/CALj2ACUyNREth8f3M7wXrHVeycfnqBn5pVygYOoBVs%3Difo8V4A%40mail.gmail.com

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com