On Thu, Mar 19, 2026 at 6:03 PM Tom Lane <[email protected]> wrote: > Please note that I was citing the runtime of a much slower machine > (longfin is a 2018 mac mini). But in any case, what I was griping > about was the additional cost added to a buildfarm run; I don't see > that test_plan_advice is a lot slower than the main regression tests. > It's just that those are already a significant investment, and we > just iterated them another time.
Right, and there's definitely plenty of worthless crap in there that isn't adding any value. For example, every \dWHATEVER command in the regression test is running basically the same queries every time, and after the first time we're probably not learning anything new. And all the DDL commands that are part of the regression tests are fairly useless here. The grison failure is actually triggered by a DDL command, but I think that might just be luck rather than the test_plan_advice module is doing anything to systematically increase the likelihood of such findings. But I don't know how we can separate the wheat from the chaff. Obviously a lot of the DDL and \d commands in the tests are either setup for queries that we should care about testing, or verification that those queries did what they were supposed to do. If we split the main regression test suite up, so that we had one test suite for planner-related stuff, another for DDL, and another for data types, or something like that, then test_plan_advice would probably mostly just need to run on the first of those. But that kind of split seems like a lot of work. Do you think the idea of piggybacking the test_plan_advice run onto another run that we're already doing has any potential? That would reduce the incremental cost quite a lot, I think. -- Robert Haas EDB: http://www.enterprisedb.com
