Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Date: 2025-12-03 15:22:23
Message-ID: 640948.1764775343@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(at)vondra(dot)me> writes:
> On 12/2/25 17:05, Tomas Vondra wrote:
>> So it was ~19h for a while (started at ~14h about 4y back). And then
>> between September 14 and 22 it jumped to ~32h. Which seems like a lot.

> After bisecting this, it seems to have changed in this commit:

> commit 1eccb93150707acfcc8f24556a15742a6313c8ac (HEAD -> stats-ext)
> Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> Date: Sat Sep 20 12:44:52 2025 -0400
> Re-allow using statistics for bool-valued functions in WHERE.

Ugh.

> Attached is a perf-report for this, but the interesting part is:
> --99.51%--plpgsql_exec_function

Yeah, I can imagine that constantly flushing the cached plan for
that plpgsql function would be bad. Let me see if I can reformulate
that test without using a plpgsql function --- right offhand, it's
not obvious why a built-in function wouldn't serve the purpose
just as well.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-12-03 15:33:53 Re: Segmentation fault on proc exit after dshash_find_or_insert
Previous Message Mircea Cadariu 2025-12-03 15:20:04 Re: Returning nbtree posting list TIDs in DESC order during backwards scans