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.
>
> And that seems to be due to stats_ext changing from
>
> ok 157 + stats_ext 855865 ms
>
> to
>
> ok 157 + stats_ext 15158426 ms
>
> That's ~14300 seconds, i.e. ~4h. Pretty close to the timeout limit. The
> machine is running the test with two locales, so there are multiple runs
> of this regression test.
>
After bisecting this, it seems to have changed in this commit:
commit 1eccb93150707acfcc8f24556a15742a6313c8ac (HEAD -> stats-ext)
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat Sep 20 12:44:52 2025 -0400
Re-allow using statistics for bool-valued functions in WHERE.
Commit a391ff3c3, which added the ability for a function's support
function to provide a custom selectivity estimate for "WHERE ...
And it seems to be "stuck" on the last few queries doing this:
SELECT * FROM check_estimated_rows('SELECT * FROM sb_2 WHERE
extstat_small(y)');
Attached is a perf-report for this, but the interesting part is:
--99.51%--plpgsql_exec_function
exec_toplevel_block.constprop.0
exec_stmt_block
exec_stmts
exec_stmt_return (inlined)
exec_eval_expr
exec_eval_simple_expr (inlined)
|
--99.37%--SPI_plan_get_cached_plan
GetCachedPlan
|
|--96.58%--RevalidateCachedQuery
| |
| |--96.00%--pg_analyze_and_rewrite_withcb
| | parse_analyze_withcb
| | |
| | --96.00%--transformTopLevelStmt (inlined)
I'm not sure if this a problem in the code, or whether it's just that
the test case happens to be this expensive with cache clobbering. Maybe
I simply need to increase the timeout for this machine, so that it does
not fail after 4h? It'd be unfortunate, as the runs are already long,
and this pushes them over 24h ... :-(
regards
--
Tomas Vondra
