MIME-Version: 1.0
From: Jerry Brenner <jbrenner@guidewire.com>
Date: Thu, 17 Jul 2025 18:09:50 -0700
Message-ID: 
 <CACoKFYRSOZFA0m33BCDHBkget30sY71hMwH9peHvTKxcV6Ha4A@mail.gmail.com>
Subject: Is there a way to identify a plan generated by GECO?
To: pgsql-performance@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000aaad0d063a29cbb9"
Archived-At: 
 <https://www.postgresql.org/message-id/CACoKFYRSOZFA0m33BCDHBkget30sY71hMwH9peHvTKxcV6Ha4A%40mail.gmail.com>
Precedence: bulk

--000000000000aaad0d063a29cbb9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.  (There is a COUNT(*) above derived table - could that be somehow
affecting this?)

I've manually explained plans and haven't seen the problem, but then it
turns up the next day (with the same parameter values) with multiple
execution plans.

One more data point - each of the individual query plans is executed in a
distinct time range (during the customer's test).  (No environment changes
between these time ranges.)  The only overlap was with one of the queries
where a single execution of a generic plan occurred during the time range
that a different plan was being executed. (The generic plan was the fastest
plan out of all of the plans.)

--000000000000aaad0d063a29cbb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We are on Postgres 15.5 (Aurora)=C2=A0 and capturing query=
 plans via auto_explain.=C2=A0 We are seeing a large number=C2=A0of query p=
lans for 2 queries that have 12 tables.=C2=A0 Every fast (or &quot;fast eno=
ugh&quot;) plan has a=C2=A0left deep tree and every slow plan has a bushy t=
ree.=C2=A0 Is there a way to determine if a plan was generated by GECO?<div=
><br></div><div>We have from_collapse_limit, join_collapse_limit and geqo_t=
hreshold all set to 12.=C2=A0 (There is a COUNT(*) above derived table - co=
uld that be somehow affecting this?)</div><div><br></div><div>I&#39;ve manu=
ally explained plans and haven&#39;t seen the problem, but then it turns up=
 the next day (with the same parameter values) with multiple execution plan=
s.</div><div><br></div><div>One more data point - each of the individual qu=
ery plans is executed in a distinct time range (during the customer&#39;s t=
est).=C2=A0 (No environment changes between these time=C2=A0ranges.)=C2=A0 =
The only overlap was with one of the queries where a single execution of a =
generic plan occurred during the time range that a different plan was being=
 executed. (The generic plan was the fastest plan=C2=A0out of all of the pl=
ans.)</div></div>

--000000000000aaad0d063a29cbb9--