Re: The issue of incorrect width estimation in UNION queries

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: "sunw(dot)fnst" <936739278(at)qq(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: The issue of incorrect width estimation in UNION queries
Date: 2025-09-24 10:47:02
Message-ID: CAApHDvofBH=aS5ZLz-Qcx0Tt9f2GH1xGLu8hdUYO69F3sY+37w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, 24 Sept 2025 at 18:13, sunw.fnst <936739278(at)qq(dot)com> wrote:
> -> Append (cost=0.00..4082.00 rows=200000 width=38) (actual time=0.016..39.050 rows=200000 loops=1)
> -> Seq Scan on t1 (cost=0.00..1541.00 rows=100000 width=11) (actual time=0.015..10.056 rows=100000 loo
> ps=1)
> -> Seq Scan on t2 (cost=0.00..1541.00 rows=100000 width=11) (actual time=0.018..10.654 rows=100000 loo
> ps=1)

This happens because in generate_union_paths() -> create_pathtarget()
-> set_pathtarget_cost_width() in get_expr_width(), the varno for the
union's RelOptInfo is 0, which results in using the get_typavgwidth()
result.

set_append_rel_size() does a better job of this for the UNION ALL code
path. Maybe we can copy the relevant parts of that.

Also, I think if we're doing this, then it'd be a master-only fix.
Changing this could result in plan changes in the back-branches, which
we normally try to avoid. The attached patch is against master. I
need to spend a bit longer on this as generate_nonunion_paths() might
need the same treatment. I've just run out of time for tonight.

David

Attachment Content-Type Size
better_width_estimates_for_union_queries.patch application/octet-stream 1.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2025-09-24 11:21:42 BUG #19062: PostgreSQL 12.22 does not compile because of conflicting types for CollationCreate
Previous Message Etsuro Fujita 2025-09-24 10:28:02 Re: TRAP: failed Assert("outerPlan != NULL") in postgres_fdw.c