Avoid using lcons and list_delete_first in plan_union_children()
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t43329psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 23, 2026 at 12:56 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t43329_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t43329_1 && git checkout t43329_1Patchset v1 (message #1) is on t43329_1
Hi,
In function plan_union_children(),
I found the lcons and list_delete_first here is easy to be replaced by lappend and list_delete_last.
And I also found a previous commit do similar thing, so I try to improve this one.
Previous commit:
d97b714a219959a50f9e7b37ded674f5132f93f3
Best regards,
houzj
On 01/12/2020 12:52, Hou, Zhijie wrote:
Hi,
In function plan_union_children(),
I found the lcons and list_delete_first here is easy to be replaced by lappend and list_delete_last.And I also found a previous commit do similar thing, so I try to improve this one.
Previous commit:
d97b714a219959a50f9e7b37ded674f5132f93f3
This doesn't matter much in practice. I was able to measure a
performance difference with a very extreme example: "SELECT 1 UNION
SELECT 2 UNION ... UNION SELECT 10000". That was about 30% faster with
this patch.
I don't see any downside, though. And like the commit message of
d97b714a21, it's better to have good examples than bad ones in the code
base, if someone copy-pastes it to somewhere where it matters.
But then again, I'm not excited about changing these one by one. If this
is worth changing, what about the one in simplify_or_arguments()? Or in
CopyMultiInsertInfoFlush()?
Perhaps it would make sense to invent a new Queue abstraction for this.
Or maybe it would be overkill..
- Heikki