Re: pg_plan_advice

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_plan_advice
Date: 2026-03-19 16:46:47
Message-ID: 1299934.1773938807@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I've now committed test_plan_advice, since it seems crazy to me to
> have pg_plan_advice in the tree without it and reviewers evidently
> agree at least with the concept test_plan_advice is something we
> should have. Here are the remaining two patches, as v21.

I just realized that this new test module has added yet another
execution of the entire core regression test suite ... and to add
insult to injury, it runs the planner twice for each plannable
query therein. I think this is an outrageous abuse of our buildfarm
and urgently request that you find some less climate-destroying
way of getting reasonable test coverage of pg_plan_advice.

As an example of what this has done to our slower buildfarm members,
a few days ago my own animal longfin could run the BF script in 32
minutes and change, if not too much recompilation was needed. Now its
minimum cycle time seems to be 35-plus minutes, or about 10% slower.
I don't think pg_plan_advice deserves that large a fraction of the
project's resources forevermore.

I don't see any good reason why you couldn't get adequate coverage of
pg_plan_advice with a few dozen queries. Certainly all the DDL
testing that happens in the core regression tests isn't adding
anything here.

I would dig into why grison and schnauzer are failing this test,
except that I don't agree that we should be running it in the
first place.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-03-19 16:54:43 Re: pg_plan_advice
Previous Message Robert Haas 2026-03-19 16:26:37 Re: dshash_find_or_insert vs. OOM