On Thu, May 20, 2021 at 9:20 AM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > From: Amit Langote <amitlangot...@gmail.com> > > On Tue, May 18, 2021 at 11:11 AM houzj.f...@fujitsu.com > > <houzj.f...@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.
I'm very glad to see such discussions on the list, because it means the partitioning feature is being stretched to cover wider set of use cases. > Is there something you're concerned about? The amount and/or complexity of > added code? IMHO, a patch that implements caching more generally would be better even if it adds some complexity. Hou-san's patch seemed centered around the use case where all rows being loaded in a given command route to the same partition, a very specialized case I'd say. Maybe we can extract the logic in Hou-san's patch to check the constant-ness of the targetlist producing the rows to insert and find a way to add it to the patch I posted such that the generality of the latter's implementation is not lost. -- Amit Langote EDB: http://www.enterprisedb.com
