ADBDEV-6520: Refactor strings into arguments when deleting/inserting into a table

[RekGRpth]

Refactor strings into arguments when deleting/inserting into a table

diskquota used long strings when deleting/inserting into the
diskquota.table_size table. This resulted in high memory consumption, both for
constructing such long strings and for parsing them. This patch reworks the
logic to use arguments consisting of arrays. As a result, significantly less
memory is spent, since the query itself is very short and there is no need to
waste memory on constructing and parsing it, array arguments are passed as is.

This patch also fixes the error duplicate key value violates unique constraint
"table_size_pkey". In the flush_to_table_size function, it may happen that when
updating the table size, the delete goes to one batch and the insert goes to
another, and the insert is performed earlier and a duplicate error occurs.

---

It is easier to view the changes with the "Hide whitespace" option enabled.

[dkovalev1]

Are there any evidence that "significantly less memory is spent" and "fixes the error duplicate key value violates unique constraint" ?

[RekGRpth]

Are there any evidence that "significantly less memory is spent" and "fixes the error duplicate key value violates unique constraint" ?

That's obvious! String representations of integer arrays take significantly more memory. And uniqueness violations will no longer happen because deletion will always happen before insertion.

[hilltracer]

Please describe in detail how I as reviewer, can check the changes in work:

• what tests check these changes?
• how can I compare memory spending before and after patch?
• how can I get this duplicate key error to verify that the patch fixes it?

[RekGRpth]

what tests check these changes?

There are no such tests.

how can I compare memory spending before and after patch?

This is practically difficult to do because you need a very large cluster with a very large number of active tables.

how can I get this duplicate key error to verify that the patch fixes it?

This is almost impossible because it would require a huge number of active tables.

how I as reviewer, can check the changes in work:

This is more of a theoretical patch.

[hilltracer]

This patch also fixes the error duplicate key ...

Please describe in more detail what the error is, how "the delete goes to one batch and the insert goes to another", and how the patch fixes this?