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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: plan with result cache is very slow when work_mem is not enough
Date: 2021-05-09 04:07:27
Message-ID: CAFj8pRBintst178s1NKdVtSAbkz+EKy2wWerOkNmM4ufT2UHRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ne 9. 5. 2021 v 3:01 odesílatel David Rowley <dgrowleyml(at)gmail(dot)com> napsal:

> On Sun, 9 May 2021 at 03:29, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
>

ok

Pavel

>
> David
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amul Sul 2021-05-09 05:26:07 Re: [Patch] ALTER SYSTEM READ ONLY
Previous Message Alexander Korotkov 2021-05-09 01:01:47 Re: JSON doc example (matchiness)