Re: apply_scanjoin_target_to_paths and partitionwise join
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>,
Tomas Vondra <tomas.vondra@enterprisedb.com>, arne.roland@malkut.net,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Julien Rouhaud <rjuju123@gmail.com>,
Etsuro Fujita <etsuro.fujita@gmail.com>, Richard Guo <guofenglinux@gmail.com>
Date: 2024-09-30T21:52:11Z
Lists: pgsql-hackers
On 24/7/2024 15:22, Ashutosh Bapat wrote: > On Wed, Jul 24, 2024 at 9:42 AM Richard Guo <guofenglinux@gmail.com> wrote: >> Is there a specific query that demonstrates benefits from this change? >> I'm curious about scenarios where a partitionwise join runs slower >> than a non-partitionwise join. > > [1] provides a testcase where a nonpartitionwise join is better than > partitionwise join. This testcase is derived from a bug reported by an > EDB customer. [2] is another bug report on psql-bugs. I haven't passed through the patch yet, but can this issue affect the decision on what to push down to foreign servers: a whole join or just a scan of two partitions? If the patch is related to the pushdown decision, I'd say it is quite an annoying problem for me. From time to time, I see cases where JOIN produces more tuples than both partitions have in total - in this case, it would be better to transfer tables' tuples to the main instance before joining them. -- regards, Andrei Lepikhov
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove redundant SET enable_partitionwise_join = on.
- 3f33b63de278 19 (unreleased) landed
-
Don't reset the pathlist of partitioned joinrels.
- 014f9a831a32 19 (unreleased) landed
-
Allow left join removals and unique joins on partitioned tables
- 3c569049b7b5 16.0 cited
-
Consider fractional paths in generate_orderedappend_paths
- 6b94e7a6da2f 15.0 cited
-
Fix handling of targetlist SRFs when scan/join relation is known empty.
- 1d338584062b 12.0 cited