Re: plan with result cache is very slow when work_mem is not enough
Yura Sokolov <y.sokolov@postgrespro.ru>
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Tomas Vondra
<tomas.vondra@enterprisedb.com>, PostgreSQL Hackers
<pgsql-hackers@lists.postgresql.org>
Date: 2021-05-09T12:57:22Z
Lists: pgsql-hackers
David Rowley писал 2021-05-09 04:01: > On Sun, 9 May 2021 at 03:29, Pavel Stehule <pavel.stehule@gmail.com> > wrote: >> 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. > > Thanks for spending the time figuring out where the slowness came from. > >> 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 > > I don't think we need to go around leaving clues for people who run > perf on cassert builds. I think anyone doing that should just never > expect any meaningful results. Occasionally there is a need to run cassert builds in production to catch an issue. It is usually ok if cassert build O(1) slower than optimized biuld (ie it is slower in some constant factor C). But if cassert build will be quadratically slower, it will unusable. regards, Yura
Commits
-
Move memory accounting Asserts for Result Cache code
- 92c4c269d24d 14.0 landed