From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Julien Rouhaud <rjuju123(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Ordered Partitioned Table Scans |
Date: | 2019-03-28 01:34:43 |
Message-ID: | e609a423-bc78-8fda-0fbf-ca12aeae30f8@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019/03/28 7:29, David Rowley wrote:
> On Wed, 27 Mar 2019 at 19:48, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> Sorry if this was discussed before, but why does this patch add any new
>> code to partprune.c? AFAICT, there's no functionality changes to the
>> pruning code.
>
> You're right. It probably shouldn't be there. There's a bit of a lack
> of a good home for partition code relating to the planner it seems.
partprune.c is outside the optimizer sub-directory, but exports
planning-related functions like prune_append_rel_partitions(),
make_partition_pruneinfo(), etc.
Similarly, partbound.c can grow bit of planning-related functionality.
>> Regarding
>>
>> +bool
>> +partitions_are_ordered(PlannerInfo *root, RelOptInfo *partrel)
>>
>> I think this could simply be:
>>
>> bool
>> partitions_are_ordered(PartitionBoundInfo *boundinfo)
>>
>> and be defined in partitioning/partbounds.c. If you think any future
>> modifications to this will require access to the partition key info in
>> PartitionScheme, maybe the following is fine:
>>
>> bool
>> partitions_are_ordered(RelOptInfo *partrel)
>
> It does need to know how many partitions the partitioned table has,
> which it gets from partrel->nparts, so yeah, RelOptInfo is probably
> needed. I don't think passing in int nparts is a good solution to
> that. The problem with moving it to partbounds.c is that nothing
> there knows about RelOptInfo currently.
Maybe, this could be a start. Also, there is a patch in nearby thread
which adds additional functionality to partbounds.c to be used by
partitionwise join code in the optimizer [1].
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-03-28 01:43:44 | Re: pg_upgrade: Pass -j down to vacuumdb |
Previous Message | Nagaura, Ryohei | 2019-03-28 01:11:23 | RE: Timeout parameters |