> On 17 Jul 2019, at 01:06, Tom Lane <t...@sss.pgh.pa.us> wrote: > There are a bunch of places that are using list_delete_first to remove > the next-to-process entry from a List used as a queue. In principle, > we could invert the order of those queues and then use list_delete_last, > but I thought this would probably be too confusing: it's natural to > think of the front of the list as being the head of the queue. I doubt > that any of those queues get long enough for it to be a serious > performance problem to leave them as-is.
For cases where an Oid list is copied and then head elements immediately
removed, as in fetch_search_path, couldn’t we instead use a counter and
list_copy_tail to avoid repeated list_delete_first calls? Something like the
attached poc.
> +List *
> +list_delete_last(List *list)
> +{
> + check_list_invariants(list);
> +
> + if (list == NIL)
> + return NIL; /* would an error be
> better? */
Since we’ve allowed list_delete_first on NIL for a long time, it seems
reasonable to do the same for list_delete_last even though it’s hard to come up
with a good usecase for deleting the last element without inspecting the list
(a stack growing from the bottom perhaps?). It reads better to check for NIL
before calling check_list_invariants though IMO.
Looking mainly at 0001 for now, I agree that the order is insignificant.
cheers ./daniel
fetch_search_path_listcopy.diff
Description: Binary data
