RE: Skip partition tuple routing with constant partition key
tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
From: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
To: 'Amit Langote' <amitlangote09@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-20T00:20:16Z
Lists: pgsql-hackers
From: Amit Langote <amitlangote09@gmail.com> > On Tue, May 18, 2021 at 11:11 AM houzj.fnst@fujitsu.com > <houzj.fnst@fujitsu.com> wrote: > > For some big data scenario, we sometimes transfer data from one table(only > store not expired data) > > to another table(historical data) for future analysis. > > In this case, we import data into historical table regularly(could be one day or > half a day), > > And the data is likely to be imported with date label specified, then all of the > data to be > > imported this time belong to the same partition which partition by time range. > > Is directing that data directly into the appropriate partition not an > acceptable solution to address this particular use case? Yeah, I know > we should avoid encouraging users to perform DML directly on > partitions, but... Yes, I want to make/keep it possible that application developers can be unaware of partitions. I believe that's why David-san, Alvaro-san, and you have made great efforts to improve partitioning performance. So, I'm +1 for what Hou-san is trying to achieve. Is there something you're concerned about? The amount and/or complexity of added code? Regards Takayuki Tsunakawa
Commits
-
Have ExecFindPartition cache the last found partition
- 3592e0ff98b1 16.0 landed
-
Fix publish_as_relid with multiple publications
- c91f71b9dc91 15.0 cited