From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
cc: Jesper Pedersen <jesper.pedersen@redhat.com>,
        Andres Freund <andres@anarazel.de>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: POC: converting Lists into arrays
In-reply-to: 
 <CAKJS1f9RUaLrujzpqf15gg_7Wo9-ai7b3-MR=bMH7a-pOWdeZA@mail.gmail.com>
References: <481.1551390571@sss.pgh.pa.us> <24783.1551568303@sss.pgh.pa.us>
 <20190303043424.itzy3ge52xrkpmpr@alap3.anarazel.de>
 <437.1551637744@sss.pgh.pa.us>
 <CA+TgmoZM4c=v0ifR++i09JFtNtnqTq_HkFmbFjwWqbUJffOLmA@mail.gmail.com>
 <12684.1551723095@sss.pgh.pa.us>
 <20190304190612.vgqqsowzkrh22623@alap3.anarazel.de>
 <26464.1551734920@sss.pgh.pa.us>
 <20190304221101.hdg4vj5fo4eewh3b@alap3.anarazel.de>
 <CAKJS1f-pNfoUJrmU8vgD1WrKLqs9WxOVLQ0RpSWu9h6W9RnypA@mail.gmail.com>
 <20190304235402.nod3gbotk2qtd4nh@alap3.anarazel.de>
 <CAKJS1f-yS201hAAmnxcLb2aeTYNZ_A9R1JNXF6hTVXjhHYN7rQ@mail.gmail.com>
 <1131.1551746172@sss.pgh.pa.us> <14626.1558745627@sss.pgh.pa.us>
 <29297.1558799327@sss.pgh.pa.us>
 <f078ce63-9e04-0f3e-d200-d7ee66279abe@redhat.com>
 <25178.1562006685@sss.pgh.pa.us> <25258.1562023641@sss.pgh.pa.us>
 <CAKJS1f9RUaLrujzpqf15gg_7Wo9-ai7b3-MR=bMH7a-pOWdeZA@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Wed, 03 Jul 2019 18:56:25 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2304.1562181615.1@sss.pgh.pa.us>
Date: Wed, 03 Jul 2019 15:20:15 -0400
Message-ID: <2305.1562181615@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> I also did some more benchmarking of the patch. ...
> Which makes the patched version 2.2% faster than master on that run.

BTW, further on the subject of performance --- I'm aware of at least
these topics for follow-on patches:

* Fix places that are maintaining arrays parallel to Lists for
access-speed reasons (at least simple_rte_array, append_rel_array,
es_range_table_array).

* Look at places using lcons/list_delete_first to maintain FIFO lists.
The patch makes these O(N^2) for long lists.  If we can reverse the list
order and use lappend/list_truncate instead, it'd be better.  Possibly in
some places the list ordering is critical enough to make this impractical,
but I suspect it's an easy win in most.

* Rationalize places that are using combinations of list_copy and
list_concat, probably by inventing an additional list-concatenation
primitive that modifies neither input.

* Adjust API for list_qsort(), as discussed, to save indirections and
avoid constructing an intermediate pointer array.  I also seem to recall
one place in the planner that's avoiding using list_qsort by manually
flattening a list into an array, qsort'ing, and rebuilding the list :-(

I don't think that any one of these fixes would move the needle very
much on "typical" simple workloads, but it's reasonable to hope that in
aggregate they'd make for a noticeable improvement.  In the meantime,
I'm gratified that the initial patch at least doesn't seem to have lost
any ground.

			regards, tom lane