From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | tomas(at)vondra(dot)me, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Subject: | Re: Reducing memory consumed by RestrictInfo list translations in partitionwise join planning |
Date: | 2024-11-24 13:30:56 |
Message-ID: | mg4ujvy2sf7t4gtptcaysif3foz4mxbkvkqz6nsnggbp6jzc3b@2awbofy3l5og |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Thu, Oct 10, 2024 at 05:36:10PM GMT, Ashutosh Bapat wrote:
>
> 3. With just patch 0001 applied, planning time usually shows
> degradation (column Q and X in planning time sheets) with or without
> PWJ enabled. I first thought that it might be because of the increased
> size of PlannerInfo. We had seen a similar phenomenon when adding a
> new member to WindowAggState [2]. Hence I introduced patch 0002 which
> moves two fields around to not increase the size of structure. But
> that doesn't fix the regression in the planning time (columns R and
> Y). Apart from increasing the PlannerInfo size and may be object file
> size, 0002 does not have any other impact. But the regression seen
> with just that patch is more than what we saw in [2]. More investigate
> is required to decide whether this regression is real or not and if
> real, the root cause. Looking at the numbers, it seems that this
> regression is causing the planning time regression in rest of the
> patches. If we fix regression by 0001, we should not see much
> regression in rest of the patches. I am looking for some guidance in
> investigating this regression.
Hi,
I've tried to reproduce some subset of those results, in case if I would
be able to notice anything useful. Strangely enough, I wasn't able to
get much boost in planning time e.g. with 4 first patches, 100
partitions and 5 joins -- the results you've posted are showing about
16% in that case, where I'm getting only a couple of percents. Probably
I'm doing something differently, but it's turned out to be hard to
reconstruct (based only on this thread) how did you exactly benchmark
the patch -- could you maybe summarize the benchmark in a reproducible
way?
From what I understand you were testing againt an empty partitioned table. Here
is what I was doing:
create table t1p (c1 int) partition by list(c1);
select format('create table %I partition of t1p for values in (%s)',
't1p' || i, i) from generate_series(1, 100) i; \gexec
do $x$
declare
i record;
plan float[];
plan_line text;
begin
for i in select * from generate_series(1, 1000) i loop
for plan_line in execute format($y$
explain analyze
select * from t1p t1, t1p t2, t1p t3, t1p t4, t1p t5
where t2.c1 =
t1.c1 and t3.c1 = t2.c1 and t4.c1 = t3.c1 and t5.c1 = t4.c1
$y$) loop
if plan_line like '%Planning Time%' then
plan := array_append(plan, substring(plan_line from '\d+.\d+')::float);
end if;
end loop;
end loop;
-- skip the first record as prewarming
raise warning 'avg: %',
(select avg(v) from unnest(plan[2:]) v);
raise warning 'median: %',
(select percentile_cont(0.5) within group(order by v)
from unnest(plan[2:]) v);
end;
$x$;
As a side note, may I ask to attach benchmark results as files, rather than a
link to a google spreadsheet? It feels nice to have something static to work
with.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-11-24 13:48:14 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Previous Message | Marcos Pegoraro | 2024-11-24 11:45:14 | Missing INFO on client_min_messages |