Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdcJ5-002oPq-0Q for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jan 2026 22:47:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdcJ4-00Fwsr-0G for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jan 2026 22:47:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdcJ3-00Fwsj-2C for pgsql-hackers@lists.postgresql.org; Wed, 07 Jan 2026 22:47:10 +0000 Received: from mail-yw1-x112c.google.com ([2607:f8b0:4864:20::112c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vdcJ1-0059xY-2Z for pgsql-hackers@lists.postgresql.org; Wed, 07 Jan 2026 22:47:10 +0000 Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-790abc54b24so24552517b3.3 for ; Wed, 07 Jan 2026 14:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767826025; x=1768430825; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mUMtwLHnIIZR33wTYOi/NZGqszf1IFTIwZhVV2Bf8uM=; b=HLwmQFIItvZdtgxd9yHCma+77tML+Ak54zgV91bU7aTuUYj5ZLFgBsDzuilogtE9RJ 52DYJ3n/U+XazckHcpr7rRTGKi4poEsV8Rp07v1oMkd9/GJJqNt8LSyUmpWJOU2DSpDF Er3MXHDV1XED7FGFgW+ibKGVLcvzUPUOCDFF+aq4u+57C0X5MwMuCWn5lS0dEx6j5/IO BFOvgH2HQJO4lJEzmOUVMcjOKiBrjxXpZNpqbNHmCV0OFKoz8q/YZuz2pRYi0neSPYwR Z4BGyl3QdXbc+L4juPiKkBbM/A9rPbpe4FQdMucOa8aCiuASYQvU0F1i6J4gyGeWpHtY kpEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767826025; x=1768430825; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=mUMtwLHnIIZR33wTYOi/NZGqszf1IFTIwZhVV2Bf8uM=; b=Oq9F9wMnd1k9dD239V02L6UX2abDjTozb3CWhN06/28cA3HjRO6pz1AF/Q2JjcBZmd vGE9U/uIYJHrl2MkMDHMtqQg9PGfEozhSUY+O1ZRqkE8MwoWvJTC5rfHv6OPYul0fl9h 95c8BqtLUFPg5Qy6ev0m/qabl8X2YVNF/jXLMZszHotXHXpRmvUUcuPO4fgYfXzIqEPX cDuRO6mEZoO4c0JGoKzcrX/LynuwiOwxu3wH74P9oz3OAXj6c6mtYWuolmtrNpY9j27J 4/LqXeIDdtKjRgAwnk9Xq3O4JreCdArTEknHR8o63ltOrUe5k6Q+zoevTaSDY9ayhVld pOAQ== X-Gm-Message-State: AOJu0YxsPXir9xhScbSyrk+PJqCIZFPltMnuxIT1iyhDd3OG1UYHed4k N+6FRv7J8WQ3gCan0RUsOtXfMOUg4ouLrZgWASRZ+6s7Vw1CtOrppS4yN16dJGukNpOqqg0dsCR owGPqlKbja3LedAi02NQHn+SWes2rrb3ovZJXUQ4= X-Gm-Gg: AY/fxX48VpOzZiWpFZMAwnsRchN2C1CFE6NZq7+9XbzIRHAwseNEbF6SZVNTcwOZOSq eFCO3uZF1pqKFkPgFEJ8UxHMn1WayDj5mVXIDTFzF9jU0yHRMc5BuWpUff2/gzQvy+VWFKx00uY DFp+Ir2oPpGZ2Qu1ajHBk3U/bGxCgd4p+KY2P+oW/R0CehqREfYmEW+Gr4nFAVbHDxXOcbvcRtT i6RvTcsY7VmDOLp1aPBWAir7YsU0y8JPbxOkaFiOqxBgI5SQ2Gn6ikjAv9Y0mTWxAFb/b0= X-Google-Smtp-Source: AGHT+IEUpmh6m+SwKvprEtcRcQpXspFn1HuQ7nOyZ0JJ2uoZO5gswhH1VAyBExNYsyfhpvVN3BeUWMESvyeEelknH/I= X-Received: by 2002:a05:690e:128e:b0:645:5cb9:dbd2 with SMTP id 956f58d0204a3-64716c7cad8mr3483852d50.67.1767826025364; Wed, 07 Jan 2026 14:47:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Haibo Yan Date: Wed, 7 Jan 2026 14:46:54 -0800 X-Gm-Features: AQt7F2oMrcxCrFtnKr_T-wqLHMZ2E-BW3kTfaZlPhOSM1H6WjQC2zZdtL7fVlaI Message-ID: Subject: Re: pg_plan_advice To: Robert Haas Cc: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="00000000000044431a0647d41292" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000044431a0647d41292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> 1. GEQO interaction (patch 4): >> Since GEQO relies on randomized search, is there a risk that the optimizer may fail to explore the specific join order or path that is being enforced by the advice mask? In that case, could this lead to failures such as inability to construct the required join relation or excessive planning time if the desired path is not sampled? > The interaction of this feature with GEQO definitely needs more study. > If you have some time to work on this, I think testing and reporting > results would be quite useful. However, I don't think we should ever > get planner failure, and I'm doubtful about excessive planning time as > well. The effect of plan advice is to disable some paths just as if > enable_ were set to false, so if you provide very specific > advice while planning with GEQO, I think you might just end up with a > disabled path that doesn't account for the advice. However, this > should be checked, and I haven't gotten there yet. I'll add an XXX to > the README to make sure this doesn't get forgotten. I conducted extensive tests today using randomized advice strings to challenge pg_plan_advice under GEQO pressure. The results strongly support your hypothesis: for standard Left-Deep trees (which GEQO natively supports), the interaction is stable and efficient. I executed a stress test involving 100,000 iterations (100 random join structures x 1000 random seeds). The planning time remained low, and no planning failures occurred for valid topology advice. Observation on Bushy Plans: I did identify one anomaly regarding "Bushy Plans" (e.g., ((t1 t2) (t3 t4))). Since PostgreSQL's GEQO implementation is strictly Left-Deep and cannot generate Bushy trees, if a user manually forges a Bushy Plan advice: It does not cause a planner crash (e.g., "failed to construct join relation"). Instead, the planner seems to silently ignore the structural constraint of the advice and falls back to a path GEQO can actually find. I believe this behavior is acceptable because pg_plan_advice is intended to stabilize plans that the optimizer can generate. Since GEQO cannot generate Bushy plans, users should not be supplying them. Script ---------------------------------------------------------------------------= -------- /* * GEQO Stress Test for pg_plan_advice * ----------------------------------- * Methodology: * 1. Generates 100 random "Left-Deep" join topologies (t1 joining t2..t100 in random orders). * 2. This simulates valid advice that GEQO is capable of producing. * 3. For each topology, runs 1000 iterations with random GEQO seeds. * 4. Measures success rate and planning time overhead. */ DO $$ DECLARE v_jo TEXT; v_jo_rest TEXT; v_nl TEXT; v_scan TEXT; v_ng TEXT; v_adv TEXT; v_sql TEXT; v_seed FLOAT; v_ok INT :=3D 0; v_err INT :=3D 0; v_msg TEXT; k INT; i INT; j INT; v_ts1 timestamp; v_ts2 timestamp; v_cur_ms numeric; v_total_ms numeric :=3D 0; v_max_ms numeric :=3D 0; BEGIN -- Pre-generate static parts of the advice to save time SELECT string_agg('t'||n, ' ' ORDER BY n) INTO v_nl FROM generate_series(2,100) n; SELECT string_agg('t'||n, ' ' ORDER BY n) INTO v_scan FROM generate_series(1,100) n; SELECT string_agg('t'||n, ' ' ORDER BY n) INTO v_ng FROM generate_series(1,100) n; -- Construct the SQL: t1 JOIN t2 JOIN t3 ... JOIN t100 v_sql :=3D 'EXPLAIN (COSTS OFF) SELECT count(*) FROM t1'; FOR j IN 2..100 LOOP v_sql :=3D v_sql || ' JOIN t' || j || ' ON t1.id=3Dt' || j || '.id'= ; END LOOP; -- Configure GEQO for stress testing (force it ON, low effort/pool) PERFORM set_config('geqo', 'on', false); PERFORM set_config('geqo_threshold', '12', false); PERFORM set_config('geqo_effort', '1', false); PERFORM set_config('geqo_pool_size', '0', false); RAISE NOTICE 'Starting Stress Test: 100 Outer Loops (Random Plans) x 1000 Inner Loops (Random Seeds)...'; -- Outer Loop: Generate 100 different valid Advice structures FOR k IN 1..100 LOOP -- Randomize the join order of t2..t100 to simulate different Left-Deep trees SELECT string_agg('t'||n, ' ' ORDER BY random()) INTO v_jo_rest FROM generate_series(2,100) n; v_jo :=3D 't1 ' || v_jo_rest; v_adv :=3D 'JOIN_ORDER(' || v_jo || ') ' || 'NESTED_LOOP_PLAIN(' || v_nl || ') ' || 'SEQ_SCAN(' || v_scan || ') ' || 'NO_GATHER(' || v_ng || ')'; PERFORM set_config('pg_plan_advice.advice', v_adv, false); -- Inner Loop: Test the specific advice against 1000 random GEQO seeds FOR i IN 1..1000 LOOP v_seed :=3D random(); PERFORM set_config('geqo_seed', v_seed::text, false); BEGIN v_ts1 :=3D clock_timestamp(); EXECUTE v_sql; v_ts2 :=3D clock_timestamp(); v_cur_ms :=3D EXTRACT(EPOCH FROM (v_ts2 - v_ts1)) * 1000; v_total_ms :=3D v_total_ms + v_cur_ms; IF v_cur_ms > v_max_ms THEN v_max_ms :=3D v_cur_ms; END IF; v_ok :=3D v_ok + 1; EXCEPTION WHEN OTHERS THEN GET STACKED DIAGNOSTICS v_msg =3D MESSAGE_TEXT; v_err :=3D v_err + 1; RAISE WARNING 'Outer % / Inner % Crashed! Seed: %, Err: %', k, i, v_seed, v_msg; END; END LOOP; RAISE NOTICE 'Batch %/100 completed.', k; END LOOP; RAISE NOTICE '---------------------------'; RAISE NOTICE 'Total Scenarios: 100,000'; RAISE NOTICE 'Success: %', v_ok; RAISE NOTICE 'Failed: %', v_err; RAISE NOTICE 'Total Time: % ms', round(v_total_ms, 2); RAISE NOTICE 'Avg Time: % ms', round(v_total_ms / (v_ok + v_err + 0.0001), 2); RAISE NOTICE 'Max Time: % ms', round(v_max_ms, 2); RAISE NOTICE '---------------------------'; IF v_err > 0 THEN RAISE NOTICE 'CONCLUSION: Conflict found.'; ELSE RAISE NOTICE 'CONCLUSION: No errors found.'; END IF; END $$; ---------------------------------------------------------------------------= -------- On Tue, Jan 6, 2026 at 11:50=E2=80=AFAM Robert Haas = wrote: > On Mon, Dec 29, 2025 at 6:34=E2=80=AFPM Haibo Yan = wrote: > > 1. GEQO interaction (patch 4): > > Since GEQO relies on randomized search, is there a risk that the > optimizer may fail to explore the specific join order or path that is bei= ng > enforced by the advice mask? In that case, could this lead to failures su= ch > as inability to construct the required join relation or excessive plannin= g > time if the desired path is not sampled? > > The interaction of this feature with GEQO definitely needs more study. > If you have some time to work on this, I think testing and reporting > results would be quite useful. However, I don't think we should ever > get planner failure, and I'm doubtful about excessive planning time as > well. The effect of plan advice is to disable some paths just as if > enable_ were set to false, so if you provide very specific > advice while planning with GEQO, I think you might just end up with a > disabled path that doesn't account for the advice. However, this > should be checked, and I haven't gotten there yet. I'll add an XXX to > the README to make sure this doesn't get forgotten. > > > 2. Parallel query serialization (patches 1=E2=80=933): > > Several new fields (subrtinfos, elidedNodes, child_append_relid_sets) > are added to PlannedStmt, but I did not see corresponding changes in > outfuncs.c / readfuncs.c. Without serialization support, parallel workers > executing subplans or Append nodes may not receive this metadata. Is this > handled elsewhere, or is it something still pending? > > I believe that gen_node_support.pl should take care of this > automatically unless the node type is flagged as > pg_node_attr(custom_read_write). > > > 3. Alias handling when generating advice (patch 5): > > In pgpa_output_relation_name, the advice string is generated using > get_rel_name(relid), which resolves to the underlying table name rather > than the RTE alias. In self-join cases this could be ambiguous (e.g., > my_table vs my_table). Would it be more appropriate to use the RTE alias > when available? > > No. That function is only used for indexes. > > > 4. Minor typo (patch 4): > > In src/include/nodes/relation.h, parititonwise appears to be a typo and > should likely be partitionwise. > > Will fix, thanks. > > -- > Robert Haas > EDB: http://www.enterprisedb.com > --00000000000044431a0647d41292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> 1. GEQO interaction (patch 4):
>> Since = GEQO relies on randomized search, is there a risk that the optimizer may fa= il to explore the specific join order or path that is being enforced by the= advice mask? In that case, could this lead to failures such as inability t= o construct the required join relation or excessive planning time if the de= sired path is not sampled?

> The interaction of this feature with= GEQO definitely needs more study.
> If you have some time to work on= this, I think testing and reporting
> results would be quite useful.= However, I don't think we should ever
> get planner failure, and= I'm doubtful about excessive planning time as
> well. The effect= of plan advice is to disable some paths just as if
> enable_<what= ever> were set to false, so if you provide very specific
> advice = while planning with GEQO, I think you might just end up with a
> disa= bled path that doesn't account for the advice. However, this
> sh= ould be checked, and I haven't gotten there yet. I'll add an XXX to=
> the README to make sure this doesn't get forgotten.

I c= onducted extensive tests today using randomized advice strings to challenge= pg_plan_advice under GEQO pressure. The results strongly support your hypo= thesis: for standard Left-Deep trees (which GEQO natively supports), the in= teraction is stable and efficient.

I executed a stress test involvin= g 100,000 iterations (100 random join structures x 1000 random seeds). The = planning time remained low, and no planning failures occurred for valid top= ology advice.

Observation on Bushy Plans: I did identify one anomaly= regarding "Bushy Plans" (e.g., ((t1 t2) (t3 t4))). Since Postgre= SQL's GEQO implementation is strictly Left-Deep and cannot generate Bus= hy trees, if a user manually forges a Bushy Plan advice:

It does not= cause a planner crash (e.g., "failed to construct join relation"= ).

Instead, the planner seems to silently ignore the structural cons= traint of the advice and falls back to a path GEQO can actually find.
I believe this behavior is acceptable because pg_plan_advice is intended = to stabilize plans that the optimizer can generate. Since GEQO cannot gener= ate Bushy plans, users should not be supplying them.

Script
-----= ---------------------------------------------------------------------------= ---
/* * GEQO Stress Test for pg_plan_advice
=C2=A0* ----------------= -------------------
=C2=A0* Methodology:
=C2=A0* 1. Generates 100 ran= dom "Left-Deep" join topologies (t1 joining t2..t100 in random or= ders).
=C2=A0* 2. This simulates valid advice that GEQO is capable of pr= oducing.
=C2=A0* 3. For each topology, runs 1000 iterations with random = GEQO seeds.
=C2=A0* 4. Measures success rate and planning time overhead.=
=C2=A0*/
DO $$
DECLARE
=C2=A0 =C2=A0 v_jo =C2=A0 =C2=A0 =C2=A0= TEXT;
=C2=A0 =C2=A0 v_jo_rest =C2=A0TEXT;
=C2=A0 =C2=A0 v_nl =C2=A0 = =C2=A0 =C2=A0 TEXT;
=C2=A0 =C2=A0 v_scan =C2=A0 =C2=A0 TEXT;
=C2=A0 = =C2=A0 v_ng =C2=A0 =C2=A0 =C2=A0 TEXT;
=C2=A0 =C2=A0 v_adv =C2=A0 =C2=A0= =C2=A0TEXT;
=C2=A0 =C2=A0 v_sql =C2=A0 =C2=A0 =C2=A0TEXT;
=C2=A0 =C2= =A0 v_seed =C2=A0 =C2=A0 FLOAT;
=C2=A0 =C2=A0 v_ok =C2=A0 =C2=A0 =C2=A0 = INT :=3D 0;
=C2=A0 =C2=A0 v_err =C2=A0 =C2=A0 =C2=A0INT :=3D 0;
=C2= =A0 =C2=A0 v_msg =C2=A0 =C2=A0 =C2=A0TEXT;
=C2=A0 =C2=A0 k =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0INT;
=C2=A0 =C2=A0 i =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0INT;
=C2=A0 =C2=A0 j =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0INT;
=C2= =A0 =C2=A0 v_ts1 =C2=A0 =C2=A0 =C2=A0timestamp;
=C2=A0 =C2=A0 v_ts2 =C2= =A0 =C2=A0 =C2=A0timestamp;
=C2=A0 =C2=A0 v_cur_ms =C2=A0 numeric;
= =C2=A0 =C2=A0 v_total_ms numeric :=3D 0;
=C2=A0 =C2=A0 v_max_ms =C2=A0 n= umeric :=3D 0;
BEGIN
=C2=A0 =C2=A0 -- Pre-generate static parts of th= e advice to save time
=C2=A0 =C2=A0 SELECT string_agg('t'||n, &#= 39; ' ORDER BY n) INTO v_nl =C2=A0 FROM generate_series(2,100) n;
= =C2=A0 =C2=A0 SELECT string_agg('t'||n, ' ' ORDER BY n) INT= O v_scan FROM generate_series(1,100) n;
=C2=A0 =C2=A0 SELECT string_agg(= 't'||n, ' ' ORDER BY n) INTO v_ng =C2=A0 FROM generate_seri= es(1,100) n;

=C2=A0 =C2=A0 -- Construct the SQL: t1 JOIN t2 JOIN t3 = ... JOIN t100
=C2=A0 =C2=A0 v_sql :=3D 'EXPLAIN (COSTS OFF) SELECT c= ount(*) FROM t1';
=C2=A0 =C2=A0 FOR j IN 2..100 LOOP
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 v_sql :=3D v_sql || ' JOIN t' || j || ' ON t1.id=3Dt' || j || '.id';
=C2=A0 = =C2=A0 END LOOP;

=C2=A0 =C2=A0 -- Configure GEQO for stress testing = (force it ON, low effort/pool)
=C2=A0 =C2=A0 PERFORM set_config('geq= o', 'on', false);
=C2=A0 =C2=A0 PERFORM set_config('geqo= _threshold', '12', false);
=C2=A0 =C2=A0 PERFORM set_config(= 'geqo_effort', '1', false);
=C2=A0 =C2=A0 PERFORM set_c= onfig('geqo_pool_size', '0', false);

=C2=A0 =C2=A0 R= AISE NOTICE 'Starting Stress Test: 100 Outer Loops (Random Plans) x 100= 0 Inner Loops (Random Seeds)...';

=C2=A0 =C2=A0 -- Outer Loop: G= enerate 100 different valid Advice structures
=C2=A0 =C2=A0 FOR k IN 1..= 100 LOOP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Randomize the join order of t2..= t100 to simulate different Left-Deep trees
=C2=A0 =C2=A0 =C2=A0 =C2=A0 S= ELECT string_agg('t'||n, ' ' ORDER BY random()) INTO v_jo_r= est FROM generate_series(2,100) n;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v_jo :=3D= 't1 ' || v_jo_rest;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 v_adv :=3D = 'JOIN_ORDER(' || v_jo || ') ' ||
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'NESTED_LOOP_PLAIN(' || v_= nl || ') ' ||
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0'SEQ_SCAN(' || v_scan || ') ' ||
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'NO_GATHER(' ||= v_ng || ')';

=C2=A0 =C2=A0 =C2=A0 =C2=A0 PERFORM set_config= ('pg_plan_advice.advice', v_adv, false);

=C2=A0 =C2=A0 =C2= =A0 =C2=A0 -- Inner Loop: Test the specific advice against 1000 random GEQO= seeds
=C2=A0 =C2=A0 =C2=A0 =C2=A0 FOR i IN 1..1000 LOOP
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_seed :=3D random();
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 PERFORM set_config('geqo_seed', v_seed::te= xt, false);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BEGIN
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_ts1 :=3D clock_times= tamp();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EXECUTE v_sql;
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_ts2 :=3D clock_timestamp();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_cur_ms :=3D EXTR= ACT(EPOCH FROM (v_ts2 - v_ts1)) * 1000;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 v_total_ms :=3D v_total_ms + v_cur_ms;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IF v_cur_ms > v_max_ms THEN
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_max_ms := =3D v_cur_ms;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EN= D IF;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_ok := =3D v_ok + 1;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 EXCEPTION WH= EN OTHERS THEN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 G= ET STACKED DIAGNOSTICS v_msg =3D MESSAGE_TEXT;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v_err :=3D v_err + 1;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RAISE WARNING 'Outer % / Inner %= Crashed! Seed: %, Err: %', k, i, v_seed, v_msg;
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 END;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 END LOOP;
= =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RAISE NOTICE &#= 39;Batch %/100 completed.', k;
=C2=A0 =C2=A0 END LOOP;

=C2=A0= =C2=A0 RAISE NOTICE '---------------------------';
=C2=A0 =C2= =A0 RAISE NOTICE 'Total Scenarios: 100,000';
=C2=A0 =C2=A0 RAISE= NOTICE 'Success: =C2=A0 =C2=A0 =C2=A0 =C2=A0 %', v_ok;
=C2=A0 = =C2=A0 RAISE NOTICE 'Failed: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0%', = v_err;
=C2=A0 =C2=A0 RAISE NOTICE 'Total Time: =C2=A0 =C2=A0 =C2=A0%= ms', round(v_total_ms, 2);
=C2=A0 =C2=A0 RAISE NOTICE 'Avg Time= : =C2=A0 =C2=A0 =C2=A0 =C2=A0% ms', round(v_total_ms / (v_ok + v_err + = 0.0001), 2);
=C2=A0 =C2=A0 RAISE NOTICE 'Max Time: =C2=A0 =C2=A0 =C2= =A0 =C2=A0% ms', round(v_max_ms, 2);
=C2=A0 =C2=A0 RAISE NOTICE '= ;---------------------------';

=C2=A0 =C2=A0 IF v_err > 0 THE= N
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RAISE NOTICE 'CONCLUSION: Conflict fou= nd.';
=C2=A0 =C2=A0 ELSE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RAISE NOTICE= 'CONCLUSION: No errors found.';
=C2=A0 =C2=A0 END IF;
END $$= ;
----------------------------------------------------------------------= -------------


On Tue, Jan 6, 2026 at 11:50=E2= =80=AFAM Robert Haas <robertmha= as@gmail.com> wrote:
On Mon, Dec 29, 2025 at 6:34=E2=80=AFPM Haibo Yan <tristan.yim@gmail.com> wrote:
> 1. GEQO interaction (patch 4):
> Since GEQO relies on randomized search, is there a risk that the optim= izer may fail to explore the specific join order or path that is being enfo= rced by the advice mask? In that case, could this lead to failures such as = inability to construct the required join relation or excessive planning tim= e if the desired path is not sampled?

The interaction of this feature with GEQO definitely needs more study.
If you have some time to work on this, I think testing and reporting
results would be quite useful. However, I don't think we should ever get planner failure, and I'm doubtful about excessive planning time as<= br> well. The effect of plan advice is to disable some paths just as if
enable_<whatever> were set to false, so if you provide very specific<= br> advice while planning with GEQO, I think you might just end up with a
disabled path that doesn't account for the advice. However, this
should be checked, and I haven't gotten there yet. I'll add an XXX = to
the README to make sure this doesn't get forgotten.

> 2. Parallel query serialization (patches 1=E2=80=933):
> Several new fields (subrtinfos, elidedNodes, child_append_relid_sets) = are added to PlannedStmt, but I did not see corresponding changes in outfun= cs.c / readfuncs.c. Without serialization support, parallel workers executi= ng subplans or Append nodes may not receive this metadata. Is this handled = elsewhere, or is it something still pending?

I believe that gen_node_support.pl should take care of this
automatically unless the node type is flagged as
pg_node_attr(custom_read_write).

> 3. Alias handling when generating advice (patch 5):
> In pgpa_output_relation_name, the advice string is generated using get= _rel_name(relid), which resolves to the underlying table name rather than t= he RTE alias. In self-join cases this could be ambiguous (e.g., my_table vs= my_table). Would it be more appropriate to use the RTE alias when availabl= e?

No. That function is only used for indexes.

> 4. Minor typo (patch 4):
> In src/include/nodes/relation.h, parititonwise appears to be a typo an= d should likely be partitionwise.

Will fix, thanks.

--
Robert Haas
EDB: http://www.enterprisedb.com
--00000000000044431a0647d41292--