zhangwenchao-123 commented on PR #1667: URL: https://github.com/apache/cloudberry/pull/1667#issuecomment-4412024883
> This reverts commit [cfd2ce4](https://github.com/apache/cloudberry/commit/cfd2ce478fea76f6cfc355aa58ea1e90a069221e). > > The reverted change normalizes COPY FROM row counts on replicated tables by dividing by the number of segments. This causes inconsistent and misleading completion tags (e.g. COPY TO reports N*segments while COPY FROM reports N for the same replicated data). > > It also produces arbitrary results in ON SEGMENT workflows used by backup/restore. For example, on a 4-segment cluster, loading three 100-row files and one empty file can report 75 rows ((100*3)/4), which is not a meaningful load count. > > Restore Greenplum-compatible behavior by reporting aggregated completed rows. > > Refs: > > * [COPY ... ON SEGMENT on REPLICATED tables: FROM returns N× in Greenplum but only 1× in Cloudberry #1298](https://github.com/apache/cloudberry/issues/1298) > * [fix(test): Skip resize cluster test for Cloudberry due to replicated table issue cloudberry-backup#36](https://github.com/apache/cloudberry-backup/pull/36) This purpose of this commit is to fix the number between copy to and copy from is different on QD when the table is replicated. Before this, the copy to always reports N rows while the copy from reports N * numsegs from the QD on replicated table. I have tested again and don't find the first problem you described. Can recheck it and give me new message? What's more, I don't understand what you mean 'on a 4-segment cluster, loading three 100-row files and one empty file can report 75 rows ((100*3)/4), which is not a meaningful load count', this commit will only influence the copy to/from on QD, can you give me more details or information to reproduce? Thx. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
