Horton

Re: plan shape work

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Alexandra Wang <alexandra.wang.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "bruce@momjian.us" <bruce@momjian.us>, lepihov@gmail.com
Date: 2025-10-09T03:04:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Assign each subquery a unique name prior to planning it.

  2. Keep track of what RTIs a Result node is scanning.

Richard Guo <guofenglinux@gmail.com> writes:
> Does it make sense to explicitly initialize glob->subplanNames in
> standard_planner()?  I understand this might seem pointless since
> makeNode() zeroes all fields by default, but subplanNames is currently
> the only field in PlannerGlobal that isn't explicitly initialized.  I
> previously committed a patch (2c0ed86d3) to ensure all PlannerGlobal
> fields are explicitly initialized, and I'd prefer to maintain that
> consistency.

We don't really have consensus on that point, I fear.  I like the
initialize-em-all-explicitly approach, but some other senior hackers
think it's useless verbiage.

My argument for doing it explicitly is that when adding a new field
to a struct, one frequently searches for existing references to a
nearby field.  Without initialize-em-all, this risks missing places
where you need to initialize your new field.  If you'd only set it
to zero, then fine ... but what if that particular place needs some
other initial value?  So I think omitting initializations-to-zero
risks future bugs of omission.  Some other folk don't find that
argument very compelling, though.

			regards, tom lane