|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|Cc:||jesper(dot)pedersen(at)redhat(dot)com, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Langote <amitlangote09(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: [HACKERS] path toward faster partition pruning|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018/04/06 7:35, Alvaro Herrera wrote:
> I seems pretty clear that putting get_matching_partitions() in
> catalog/partition.c is totally the wrong thing; it belongs wholly in
> partprune. I think the reason you put it there is that it requires
> access to a lot of internals that are static in partition.c. In the
> attached not yet cleaned version of the patch, I have moved a whole lot
> of what you added to partition.c to partprune.c; and for the functions
> and struct declarations that were required to make it work, I created
Yes, I really wanted for most of the new code that this patch adds to land
in the planner, especially after Robert's comments here:
It would've been nice if we'd gotten the "reorganizing partitioning code"
thread resolved sooner.
> I changed a lot of code also, but cosmetic changes only.
> I'll clean this up a bit more now, and try to commit shortly (or early
> tomorrow); wanted to share current status now in case I have to rush
Some comments on the code reorganizing part of the patch:
* Did you intentionally not put PartitionBoundInfoData and its accessor
macros in partition_internal.h. partprune.c would not need to include
partition.h if we do that.
* Also, I wonder why you left PartitionPruneContext in partition.h. Isn't
it better taken out to partprune.h?
I have done that in the attached.
* Why isn't gen_partprune_steps() in partprune.h? I see only
prune_append_rel_partitions() exported out of partprune.c, but the runtime
patch needs gen_partprune_steps() to be called from createplan.c.
* I don't see get_matching_partitions() exported either. Runtime pruning
patch needs that too.
Maybe you've thought something about these two items though.
|Next Message||Masahiko Sawada||2018-04-06 01:52:58||Re: [HACKERS] GUC for cleanup indexes threshold.|
|Previous Message||Peter Eisentraut||2018-04-06 01:29:06||Re: PATCH: psql tab completion for SELECT|