On Thu, Dec 7, 2023 at 6:19 PM David Rowley <dgrowle...@gmail.com> wrote: > > Maybe we can try to move forward with your refcount idea and see how > the performance looks. If that's intolerable then that might help us > decide on the next best alternative solution. >
Here are performance numbers setup create table t1 (a integer primary key, b integer); create table t1_parted (a integer primary key, b integer) partition by range(a); create 1000 partitions of t1 query (a five way self-join) select * from t1 a, t1 b, t1 c, t1 d, t1 e where a.a = b.a and b.a = c.a and c.a = d.a and d.a = e.a -- unpartitioned table case select * from t1_parted a, t1_parted b, t1_parted c, t1_parted d, t1_parted e where a.a = b.a and b.a = c.a and c.a = d.a and d.a = e.a; -- partitioned table case The numbers with patches attached to [1] with limitations listed in the email are thus Ran each query 10 times through EXPLAIN (SUMMARY) and averaged planning time with and without patch. unpartitioned case without patch: 0.25 with patch: 0.19 this improvement is probably misleading. The planning time for this query change a lot. partitioned case (without partitionwise join) without patch: 14580.65 with patch: 14625.12 % degradation: 0.3% partitioned case (with partitionwise join) without patch: 23273.69 with patch: 23328.52 % degradation: 0.2% That looks pretty small considering the benefits. What do you think? [1] https://www.postgresql.org/message-id/caexhw5stmouobe55pmt83r8uxvfcph+pvo5dnpdrvcsbgxe...@mail.gmail.com -- Best Wishes, Ashutosh Bapat
