Re: reorganizing partitioning code (was: Re: [HACKERS] path towardfaster partition pruning) - Mailing list pgsql-hackers

From Amit Langote
Subject Re: reorganizing partitioning code (was: Re: [HACKERS] path towardfaster partition pruning)
Date
Msg-id 610e62ab-0836-4c4c-d296-87542e31c36d@lab.ntt.co.jp
Whole thread Raw
In response to reorganizing partitioning code (was: Re: [HACKERS] path toward fasterpartition pruning)  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
On 2018/02/13 23:08, Ashutosh Bapat wrote:
> On Tue, Feb 13, 2018 at 2:17 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>
>> Agree with the proposed reorganizing and adding a partcache.c, which I
>> tried to do in the attached patch.
>>
>> * The new src/backend/utils/cache/partcache.c contains functions that
>> initialize relcache's partitioning related fields.  Various partition
>> bound comparison and search functions (and then some) that work off of the
>> cached information are moved.
>
> Are you moving partition bound comparison functions to partcache.c?
> They will also used by optimizer, so may be leave them out of
> partcache.c?

Yes, I moved the partition bound comparison and search functions, because
I thought that they should live with the other code that manages the
cached information.  So, I moved not only the code that reads the catalogs
and builds the partition key, partition (bound) descriptor, and partition
qual (for individual partitions), but also the code that uses those
structures.

So, with the new arrangement, optimizer will include utils/partcache.h,
instead of catalog/partition.h.

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Jaime Casanova
Date:
Subject: tapeblocks is uninitialized in logtape.c
Next
From: Tatsuo Ishii
Date:
Subject: Parameter status message not sent?