From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Avoid using lcons and list_delete_first in plan_union_children() |
Date: | 2020-12-01 16:17:24 |
Message-ID: | f76c16ad-fd0a-191a-19b5-c899180a11bf@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Laurenz Albe | 2020-12-01 16:21:11 | Re: Confusing behavior of psql's \e |
Previous Message | Alexander Korotkov | 2020-12-01 16:13:53 | Re: Phrase search vs. multi-lexeme tokens |