|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:||PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Speeding up INSERTs and UPDATEs to partitioned tables|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2018/07/28 10:54, David Rowley wrote:
> On 27 July 2018 at 19:11, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> I've attached a delta patch to make the above changes. I'm leaving the
>> hash table rename up to you though.
> Thanks for the delta patch. I took all of it, just rewrote a comment slightly.
> I also renamed the hash table to your suggestion and changed a few more things.
> Attached a delta based on v2 and the full v3 patch.
> This includes another small change to make
> PartitionDispatchData->indexes an array that's allocated in the same
> memory as the PartitionDispatchData. This will save a palloc() call
> and also should be a bit more cache friendly.
> This also required a rebase on master again due to 3e32109049.
Thanks for the updated patch.
I couldn't find much to complain about in the latest v3, except I noticed
a few instances of the word "setup" where I think what's really meant is
+ * must be setup, but any sub-partitioned tables can be setup lazily as
+ * A ResultRelInfo has not been setup for this partition yet,
By the way, when going over the updated code, I noticed that the code
around child_parent_tupconv_maps could use some refactoring too.
Especially, I noticed that ExecSetupChildParentMapForLeaf() allocates
child-to-parent map array needed for transition tuple capture even if not
needed by any of the leaf partitions. I'm attaching here a patch that
applies on top of your v3 to show what I'm thinking we could do.
|Next Message||Peter Eisentraut||2018-07-30 08:33:36||Re: Making "COPY partitioned_table FROM" faster|
|Previous Message||Arthur Zakirov||2018-07-30 08:24:14||Re: adding tab completions|