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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Pavel Stehule <pavel(dot)stehule(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 01:01:12
Message-ID: CAApHDvrJvhj2E9taBH13Nr1eVDyg1A9UuXz1xeWQDaLagWsTTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2021-05-09 01:01:47 Re: JSON doc example (matchiness)
Previous Message Zhihong Yu 2021-05-08 23:54:02 Re: SQL/JSON: functions