From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Yuya Watari <watari(dot)yuya(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, jian he <jian(dot)universality(at)gmail(dot)com>, Alena Rybakina <lena(dot)ribackina(at)yandex(dot)ru>, Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Thom Brown <thom(at)linux(dot)com>, Zhang Mingli <zmlpostgres(at)gmail(dot)com> |
Subject: | Re: [PoC] Reducing planning time when tables have many partitions |
Date: | 2025-04-04 14:22:57 |
Message-ID: | CAApHDvqGBsm_AXwbxTqPRiznbwP8eVgkgqfYPPbLsyWDjmiP1g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 5 Apr 2025 at 02:54, Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> I haven't measured if the patches improve performance of simple scans
> with thousands of partitions. Have you tried measuring that?
I just tried 10k partitions on my Zen4 laptop.
create table lp (a int) partition by list(a);
select 'create table lp'||x||' partition of lp for values
in('||x||');' from generate_Series(1,10000)x;
\gexec
create index on lp(a);
explain (summary on) select * from lp order by a;
master:
Planning Time: 2296.227 ms
Planning Time: 2142.999 ms
Planning Time: 2089.924 ms
Memory: used=84701kB allocated=85292kB
59.34% postgres [.] bms_is_subset
17.09% postgres [.] find_ec_member_matching_expr
11.55% postgres [.] bms_equal
3.41% postgres [.] get_eclass_for_sort_expr
2.08% postgres [.] add_child_rel_equivalences
0.59% postgres [.] SearchCatCacheInternal
0.52% postgres [.] hash_search_with_hash_value
0.45% libc.so.6 [.] __memmove_avx512_unaligned_erms
0.23% postgres [.] AllocSetAlloc
0.16% postgres [.] ResourceOwnerForget
0.13% postgres [.] add_paths_to_append_rel
0.12% postgres [.] RelationIdGetRelation
0.11% postgres [.] create_scan_plan
0.11% libc.so.6 [.] __memset_avx512_unaligned_erms
0.10% postgres [.] uint32_hash
0.10% libc.so.6 [.] __memcmp_evex_movbe
0.10% postgres [.] lappend
patched:
Planning Time: 118.346 ms
Planning Time: 122.706 ms
Planning Time: 120.424 ms
Memory: used=77677kB allocated=84752kB
9.58% postgres [.] hash_search_with_hash_value
7.58% libc.so.6 [.] __memmove_avx512_unaligned_erms
6.41% postgres [.] SearchCatCacheInternal
3.35% postgres [.] AllocSetAlloc
3.15% postgres [.] bms_next_member
2.79% postgres [.] ResourceOwnerForget
2.07% postgres [.] RelationIdGetRelation
1.86% libc.so.6 [.] __memcmp_evex_movbe
1.78% postgres [.] add_paths_to_append_rel
1.57% postgres [.] LockAcquireExtended
1.35% postgres [.] uint32_hash
1.29% libc.so.6 [.] __memset_avx512_unaligned_erms
David
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-04-04 14:28:27 | Re: Large expressions in indexes can't be stored (non-TOASTable) |
Previous Message | Heikki Linnakangas | 2025-04-04 14:04:18 | Re: autoprewarm_dump_now |