Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CAFjFpRd-mXV3Ys9C096e_=z+T9=ot4S3bYbSsJFNKqQPreCMuA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] path toward faster partition pruning
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: MCV lists for highly skewed distributions
Next
From: Robert Haas
Date:
Subject: Re: Obsolete fmgr() declaration in fmgr.h