Thanks a lot for the fast reply!
On 03.11.2022 18:29, Tom Lane wrote:
> If we were just adding a
> query or two to an existing scenario, that could be okay; but spinning
> up and syncing a whole new primary and standby database is *expensive*
> when you multiply it by the number of times developers and buildfarm
> animals are going to run the tests in the future.
>
On 15.11.2022 04:59, Tom Lane wrote:
> "Anton A. Melnikov" <aamelnikov@inbox.ru> writes:
>> On 02.11.2022 21:02, Tom Lane wrote:
>>> I don't think the cost of that test case is justified by the tiny
>>> probability that it'd ever catch anything.
>
>> Seems it is possible to do a test without these remarks. The attached
>> test uses existing nodes and checks the specific error message.
>
> My opinion remains unchanged: this would be a very poor use of test
> cycles.
Sorry, i didn't fully understand what is required and
added some functions to the test that spend extra cpu time. But i found
that it is possible to make a test according to previous remarks by adding
only a few extra queries to an existent test without any additional syncing.
Experimentally, i could not observe any significant difference in
CPU usage due to this test addition.
The difference in the CPU usage was less than standard error.
See 100_bugs-CPU-time.txt attached.
>> Additionally
>> i've tried to reduce overall number of nodes previously
>> used in this test in a similar way.
>
> Optimizing existing tests isn't an answer to that. We could
> install those optimizations without adding a new test case.
Oh sure! Here is a separate patch for this optimization:
https://www.postgresql.org/message-id/eb7aa992-c2d7-6ce7-4942-0c784231a362%40inbox.ru
On the contrary with previous case in that one the difference in the CPU usage
during 100_bugs.pl is essential; it decreases approximately by 30%.
With the best wishes!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company