From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: POC: converting Lists into arrays |
Date: | 2019-07-22 01:15:06 |
Message-ID: | CAKJS1f_OgANSMp+W_FXJWCN3yLMCE_pLfv-Y-U16vwaPtgL0Og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 22 Jul 2019 at 02:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
> (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.)
My 2nd test was for when all subplans were present in the bitmap. It
did show a very slight slowdown for the case were all subplans were
present in the bitmapset. However, yeah, it seems like a good idea to
try it a million times to help show the true cost.
I did:
int x = 0;
/* Patched version */
for (j = 0; j < 1000000; j++)
{
i = -1;
while ((i = bms_next_member(validsubplans, i)) >= 0)
{
Plan *initNode = (Plan *) list_nth(node->appendplans, i);
x++;
}
}
/* Master version */
for (j = 0; j < 1000000; j++)
{
ListCell *lc;
i = 0;
foreach(lc, node->appendplans)
{
Plan *initNode;
if (bms_is_member(i, validsubplans))
{
initNode = (Plan *)lfirst(lc);
x++;
}
}
}
elog(DEBUG1, "%d", x); /* stop the compiler optimizing away the loops */
I separately commented out each one of the outer loops away before
performing the test again.
plan_cache_mode = force_generic_plan
-- Test 1 (one matching subplan) --
prepare q1(int) as select * from ht where a = $1;
execute q1(1);
Master version:
Time: 14441.332 ms (00:14.441)
Time: 13829.744 ms (00:13.830)
Time: 13753.943 ms (00:13.754)
Patched version:
Time: 41.250 ms
Time: 40.976 ms
Time: 40.853 ms
-- Test 2 (all matching subplans (8192 of them)) --
prepare q2 as select * from ht;
execute q2;
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. In realiy, the ExecInitNode() call drowns most of it out.
Plus a plan with more subnodes is going take longer to execute and
then shutdown the plan after too.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-07-22 01:21:04 | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Previous Message | Michael Paquier | 2019-07-22 01:05:50 | Re: Fix typos and inconsistencies for HEAD (take 7) |