Re: reorganizing partitioning code (was: Re: [HACKERS] path toward faster partition pruning)

From: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Subject: Re: reorganizing partitioning code (was: Re: [HACKERS] path toward faster partition pruning)
Date: 2018-02-14 02:10:58
Message-ID: 610e62ab-0836-4c4c-d296-87542e31c36d@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)lab(dot)ntt(dot)co(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2018-02-14 02:12:30 Parameter status message not sent?
Previous Message Jaime Casanova 2018-02-14 02:09:32 tapeblocks is uninitialized in logtape.c