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: 
 <CAKJS1f_OgANSMp+W_FXJWCN3yLMCE_pLfv-Y-U16vwaPtgL0Og@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> <1733.1563720332@sss.pgh.pa.us>
 <CAKJS1f_OgANSMp+W_FXJWCN3yLMCE_pLfv-Y-U16vwaPtgL0Og@mail.gmail.com>
Comments: In-reply-to David Rowley <david.rowley@2ndquadrant.com>
	message dated "Mon, 22 Jul 2019 13:15:06 +1200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29071.1563770256.1@sss.pgh.pa.us>
Date: Mon, 22 Jul 2019 00:37:36 -0400
Message-ID: <29072.1563770256@sss.pgh.pa.us>
Precedence: bulk

David Rowley <david.rowley@2ndquadrant.com> writes:
> On Mon, 22 Jul 2019 at 02:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> ...
> -- Test 2 (all matching subplans (8192 of them)) --

> Master version:

> Time: 14825.304 ms (00:14.825)
> Time: 14701.601 ms (00:14.702)
> Time: 14650.969 ms (00:14.651)

> Patched version:

> Time: 44551.811 ms (00:44.552)
> Time: 44357.915 ms (00:44.358)
> Time: 43454.958 ms (00:43.455)

> So the bms_next_member() loop is slower when the bitmapset is fully
> populated with all subplans, but way faster when there's just 1
> member.

Interesting.  I wonder if bms_next_member() could be made any quicker?
Still, I agree that this is negligible compared to the actual work
needed per live subplan, and the fact that the cost scales per live
subplan is a good thing.  So no objection to this patch, but a mental
note to take another look at bms_next_member() someday.

			regards, tom lane