From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jerry Brenner <jbrenner@guidewire.com>
cc: pgsql-performance@lists.postgresql.org
Subject: Re: Is there a way to identify a plan generated by GECO?
In-reply-to: 
 <CACoKFYRSOZFA0m33BCDHBkget30sY71hMwH9peHvTKxcV6Ha4A@mail.gmail.com>
References: 
 <CACoKFYRSOZFA0m33BCDHBkget30sY71hMwH9peHvTKxcV6Ha4A@mail.gmail.com>
Comments: In-reply-to Jerry Brenner <jbrenner@guidewire.com>
	message dated "Thu, 17 Jul 2025 18:09:50 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1761500.1752803865.1@sss.pgh.pa.us>
Date: Thu, 17 Jul 2025 21:57:45 -0400
Message-ID: <1761501.1752803865@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1761501.1752803865%40sss.pgh.pa.us>
Precedence: bulk

Jerry Brenner <jbrenner@guidewire.com> writes:
> We are on Postgres 15.5 (Aurora)  and capturing query plans via
> auto_explain.  We are seeing a large number of query plans for 2 queries
> that have 12 tables.  Every fast (or "fast enough") plan has a left deep
> tree and every slow plan has a bushy tree.  Is there a way to determine if
> a plan was generated by GECO?

> We have from_collapse_limit, join_collapse_limit and geqo_threshold all set
> to 12.

If there are 12 tables used in the query, then setting the collapse
limits to 12 would allow the join search to be collapsed into a single
problem, and then it would *always* go to GEQO because we invoke GEQO
if the join problem involves >= geqo_threshold tables.  You might want
to rethink having those settings equal to each other.

> I've manually explained plans and haven't seen the problem,

My guess is that GEQO usually finds one of the better plans, but
when its randomized search is particularly unlucky it fails to.
Try bumping geqo_threshold to more than 12, and note whether that
results in unacceptable planning time for these queries.  If not,
leave it at the higher value.

			regards, tom lane