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: 
 <CAKJS1f8ZcsLVgkF4wOfRyMYTcPgLFiUAOedFC+U2vK_aFZk-BA@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>
 <2305.1562181615@sss.pgh.pa.us> <21272.1563318411@sss.pgh.pa.us>
 <CAKJS1f8ZcsLVgkF4wOfRyMYTcPgLFiUAOedFC+U2vK_aFZk-BA@!
 mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Mon, 22 Jul 2019 01:32:00 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1732.1563720332.1@sss.pgh.pa.us>
Date: Sun, 21 Jul 2019 10:45:32 -0400
Message-ID: <1733.1563720332@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> On Wed, 17 Jul 2019 at 11:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Actually, I doubt that any of these changes will really move the
>> performance needle in the real world.  It's more a case of wanting
>> the code to present good examples not bad ones.)

> In spirit with the above, I'd quite like to fix a small bad example
> that I ended up with in nodeAppend.c and nodeMergeappend.c for
> run-time partition pruning.

I didn't test the patch, but just by eyeball it looks sane,
and I concur it should win if the bitmap is sparse.

One small question is whether it loses if most of the subplans
are present in the bitmap.  I imagine that would be close enough
to break-even, but it might be worth trying to test to be sure.
(I'd think about breaking out just the loops in question and
testing them stand-alone, or else putting in an outer loop to
repeat them, since as you say the surrounding work probably
dominates.)

			regards, tom lane