Re: [HACKERS] path toward faster partition pruning
От | Ashutosh Bapat |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | CAFjFpRd-mXV3Ys9C096e_=z+T9=ot4S3bYbSsJFNKqQPreCMuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] path toward faster partition pruning
|
Список | pgsql-hackers |
On Wed, Feb 7, 2018 at 6:49 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Feb 7, 2018 at 3:42 AM, Ashutosh Bapat > <ashutosh.bapat@enterprisedb.com> wrote: >> partprune.c looks to much tied to one feature. I am sure that the >> functions used for partition pruning can be used by other >> optimizations as well. > > Uh, I don't know about that, this code looks like it does partition > pruning specifically, and nothing else. How else do you think it > could be used? I didn't have any specific thing in mind, and now more I think, it looks less likely that it will be used for something else. While looking at the changes in partition.c I happened to look at the changes in try_partition_wise_join(). They mark partitions deemed dummy by pruning as dummy relations. If we accept those changes, we could very well change the way we handle dummy partitioned tables, which would mean that we also revert the recent commit f069c91a5793ff6b7884120de748b2005ee7756f. But I guess, those changes haven't been reviewed yet and so not final. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
В списке pgsql-hackers по дате отправления: