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