From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Date: | 2020-09-28 02:47:22 |
Message-ID: | CAApHDvrn=7wJ9Khb-6DdhZBv_gqre4kvymJYnZdd+Mfcok+E8g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thanks for 9d299a492.
On Mon, 28 Sep 2020 at 15:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Poking around to count remaining uses of those inline functions,
> I found a few places that should be using the macros instead,
> and fixed them. After that, I notice that list_tail(),
> list_third_cell(), and list_fourth_cell() are entirely unreferenced.
> I'm hesitant to get rid of list_tail(), because it seems like it
> could well be used by extensions. But I'd bet quite a bit that
> list_third_cell() and list_fourth_cell() are not used anywhere
> anymore. Should we get rid of them to shave a few microseconds
> from compile times?
I wouldn't object to the removal of list_third_cell() and list_fourth_cell().
I agree to your reasoning with last_tail(). It does seem more likely
that someone would use it. Although, if you'd proposed to remove it
too, I wouldn't have objected. It's not like it's hard to reimplement
within an extension for any extensions that use it. Though, perhaps it
would maybe be a shame if that was the sole thing we broke for them
when they try compiling their extension in a year's time on the newly
release PG14.
David
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-09-28 02:50:20 | RE: [Patch] Optimize dropping of relation buffers using dlist |
Previous Message | Amit Kapila | 2020-09-28 02:46:16 | Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables |