Re: POC: converting Lists into arrays
От | Daniel Gustafsson |
---|---|
Тема | Re: POC: converting Lists into arrays |
Дата | |
Msg-id | 3C77817B-959F-4D70-ABB1-97FFA478F1AE@yesql.se обсуждение исходный текст |
Ответ на | Re: POC: converting Lists into arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: POC: converting Lists into arrays
|
Список | pgsql-hackers |
> On 17 Jul 2019, at 01:06, Tom Lane <tgl@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
Вложения
В списке pgsql-hackers по дате отправления: