Re: Skip partition tuple routing with constant partition key
От | Amit Langote |
---|---|
Тема | Re: Skip partition tuple routing with constant partition key |
Дата | |
Msg-id | CA+HiwqG0cXY9PZ7-0UECa1Qc+uVhC=3ktLgLZXOYATPhBu1M_w@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Skip partition tuple routing with constant partition key ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Список | pgsql-hackers |
On Thu, May 20, 2021 at 9:20 AM tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com> wrote: > 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 istrying 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
В списке pgsql-hackers по дате отправления: