Another modest proposal for reducing CLOBBER_CACHE_ALWAYS runtime
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2021-05-10T06:03:58Z
Lists: pgsql-hackers
Attachments
- make-leak-a-C-function.patch (text/x-diff) patch
I noted that, while privileges.sql doesn't stand out in terms of runtime normally (it's only the fourth slowest test in its parallel group), it looks absolutely horrid in CLOBBER_CACHE_ALWAYS testing. On hyrax's latest run, it takes nearly 9000 seconds longer than the next-slowest member of its group. Remembering that the core regression tests are run thrice in a minimal buildfarm cycle, this test is single-handedly responsible for over seven hours of the 54 hour total build cycle. I dug into it and found that the core issue is much like that in opr_sanity.sql, namely that we're repeating this plpgsql function $bignum times: CREATE FUNCTION leak(integer,integer) RETURNS boolean AS $$begin return $1 < $2; end$$ LANGUAGE plpgsql immutable; (I wonder whether the planner needs to invoke this function quite so many times during selectivity estimation. But, again, improving that seems like a task for some other day.) Now, as far as I can see, this function definition isn't doing anything we can't do with an alias for the underlying int4lt function: the fact that the implementation is in plpgsql shouldn't matter at all for the purposes of this test. So I replaced it, as per the attached patch. On my machine, the time to run privileges.sql under debug_invalidate_system_caches_always = 1 drops from real 293m31.054s to real 1m47.807s Yes, really. regards, tom lane
Commits
-
Reduce runtime of privileges.sql test under CLOBBER_CACHE_ALWAYS.
- e135743ef07e 14.0 landed
- 834d9284b4fe 13.4 landed