Re: POC: converting Lists into arrays

David Rowley <david.rowley@2ndquadrant.com>

From: David Rowley <david.rowley@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-06-14T02:05:19Z
Lists: pgsql-hackers
On Fri, 14 Jun 2019 at 13:54, Bruce Momjian <bruce@momjian.us> wrote:
>
> On Sat, May 25, 2019 at 11:48:47AM -0400, Tom Lane wrote:
> > I wrote:
> > > Here's a new version of the Lists-as-arrays patch.
> >
> > The cfbot noticed a set-but-not-used variable that my compiler hadn't
> > whined about.  Here's a v5 to pacify it.  No other changes.
>
> Have you tested the performance impact?

I did some and posted earlier in the thread:
https://postgr.es/m/CAKJS1f8h2vs8M0cgFsgfivfkjvudU5-MZO1gJB2uf0m8_9VCpQ@mail.gmail.com

It came out only slightly slower over the whole regression test run,
which I now think is surprisingly good considering how much we've
tuned the code over the years with the assumption that List is a
singly linked list.  We'll be able to get rid of things like
PlannerInfo's simple_rte_array and append_rel_array along with
EState's es_range_table_array.

I'm particularly happy about getting rid of es_range_table_array since
initialising a plan with many partitions ends up costing quite a bit
just to build that array. Run-time pruning might end up pruning all
but one of those, so getting rid of something that's done per
partition is pretty good.  (There's also the locking, but that's
another problem).

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



Commits

  1. Remove EState.es_range_table_array.

  2. Rationalize use of list_concat + list_copy combinations.

  3. Cosmetic improvements in setup of planner's per-RTE arrays.

  4. Make better use of the new List implementation in a couple of places

  5. Fix sepgsql test results for commit d97b714a2.

  6. Avoid using lcons and list_delete_first where it's easy to do so.

  7. Remove lappend_cell...() family of List functions.

  8. Clean up some ad-hoc code for sorting and de-duplicating Lists.

  9. Redesign the API for list sorting (list_qsort becomes list_sort).

  10. Remove dead code.

  11. Represent Lists as expansible arrays, not chains of cons-cells.

  12. Standardize some more loops that chase down parallel lists.

  13. Reimplement the linked list data structure used throughout the backend.