Re: plan with result cache is very slow when work_mem is not enough
От | Yura Sokolov |
---|---|
Тема | Re: plan with result cache is very slow when work_mem is not enough |
Дата | |
Msg-id | 2a23a9ca2c6f36f70205cb95a6905672@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: plan with result cache is very slow when work_mem is not enough (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: plan with result cache is very slow when work_mem is not enough
|
Список | 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
В списке pgsql-hackers по дате отправления: