Re: [HACKERS] ArrayLists instead of List (for some things)

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: [HACKERS] ArrayLists instead of List (for some things)
Date: 2018-12-21 21:57:00
Message-ID: CAKJS1f_H6_=LtqE-TQziRaSK1DRqo2UjRt93y3zCufHm7YkNEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 3 Nov 2017 at 03:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> > Comments on the design are welcome, but I was too late to the
> > commitfest, so there are other priorities. However, if you have a
> > strong opinion, feel free to voice it.
>
> I do not like replacing Lists piecemeal; that's a recipe for ongoing
> API breakage and back-patching pain. Plus we'll then have *four*
> different linked-list implementations in the backend, which sure
> seems like too many.
>
> We've jacked up the List API and driven a new implementation underneath
> once before. Maybe it's time to do that again.

(reviving this old thread as it's still on my list of things to work on)

How would you feel if I submitted a patch that changed all locations
where we test for an empty list with: if (list) or if (list == NIL) to
a more standard form of if (list_is_empty(list)) ?

The idea here is that I'd like a way to preallocate memory for a list
to a given size before we start populating it, and that flies in the
face of how we currently test for list emptiness.

Such a macro could be backpatched to assist extensions.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2018-12-21 22:16:05 Re: Use an enum for RELKIND_*?
Previous Message David Rowley 2018-12-21 21:53:46 Re: Performance issue in foreign-key-aware join estimation