| 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
| 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 |