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 |
Date: | 2018-10-09 02:49:48 |
Message-ID: | 4cec6854-1443-095b-c970-b9a184be7d0d@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi David,
On 2018/10/05 21:55, David Rowley wrote:
> On 17 September 2018 at 21:15, David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>> v9 patch attached. Fixes conflict with 6b78231d.
>
> v10 patch attached. Fixes conflict with cc2905e9.
Thanks for rebasing.
> I'm not so sure we need to zero the partition_tuple_slots[] array at
> all since we always set a value there is there's a corresponding map
> stored. I considered pulling that out, but in the end, I didn't as I
> saw some Asserts checking it's been properly set by checking the
> element != NULL in nodeModifyTable.c and copy.c. Perhaps I should
> have just gotten rid of those Asserts along with the palloc0 and
> subsequent memset after the expansion of the array. I'm undecided.
Maybe it's a good thing that it's doing the same thing as with the
child_to_parent_maps array, which is to zero-init it when allocated.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-10-09 02:49:50 | Re: pread() and pwrite() |
Previous Message | Haribabu Kommi | 2018-10-09 02:46:34 | Re: Pluggable Storage - Andres's take |