Re: plan with result cache is very slow when work_mem is not enough

so 8. 5. 2021 v 9:39 odesílatel David Rowley <dgrowleyml(at)gmail(dot)com> napsal:

> On Sat, 8 May 2021 at 19:03, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
> wrote:
> > Perhaps there is need for flag "heavy asserts". Or option
> "--enable-cassert=heavy". Then USE_ASSERT_CHECKING could be defined to
> integer 1 or 2 depending on "heaviness" of enabled checks.
>
> I'd rather explore all other options before we went and did something
> like that. The reason I feel this way is; a couple of jobs ago, I
> worked on a project that had quite a large test suite. In order to
> run the tests on a typical dev machine took about 16 hours. When
> writing new tests, nobody really ever gave much thought to how long
> tests would take to run. The time it took had already grown to
> something much longer than was practical to run before a commit.
> Instead, we had a test farm. We'd commit to master (yuck) and the test
> farm would run the tests. Unfortunately, the farm was not big enough
> to run every test on every commit, so if it encountered a test failure
> (as it commonly did) it tried to bisect and find the first breaking
> commit for that test then alert the person (probably the next day).
> bisecting works out pretty badly when someone commits a build breaking
> commit.
>
> Now that I work on PostgreSQL, I very much like the fact that I can
> run make check-world -j and see very quickly that no tests fail. I'd
> rather not have something like heavy asserts as I believe it would
> just become a dumping ground for badly thought through Asserts that
> most likely could be done in some better way that didn't require so
> much effort. (I'll put mine in that category) It might not take long
> before most committers opted to run make check-world without the heavy
> asserts because it became just too slow. When that happens, it means
> the buildfarm is left to catch these errors and most likely the
> feedback will take much longer to get back to the committer due to the
> animals running these flags also having to churn through the slow
> tests.
>
> So, I'm -1 for "heavy asserts".
>

Personally, I have not problem with too slow assertions, although it is not
too practical. The main problem is some shock, and feeling so some is
wrong. I spent 1 hour detecting if it is a bug or not.

Can it be possible to identify this situation?

Maybe use some specific name of this routine - like

assert_only_check_xxxx

Then I can see this warning in perf, and I don't need to do other or deeper
checks

Regards

Pavel

> David
>