Re: Speeding up INSERTs and UPDATEs to partitioned tables - Mailing list pgsql-hackers

From David Rowley
Subject Re: Speeding up INSERTs and UPDATEs to partitioned tables
Date
Msg-id CAKJS1f9CqGoPL6=DZjhYWv7GKGjHTY_QpdS7JbnEQ3GyZrK-mA@mail.gmail.com
Whole thread Raw
In response to Re: Speeding up INSERTs and UPDATEs to partitioned tables  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Speeding up INSERTs and UPDATEs to partitioned tables  (Krzysztof Nienartowicz <krzysztof.nienartowicz@gmail.com>)
List pgsql-hackers
On 9 October 2018 at 15:49, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/10/05 21:55, David Rowley wrote:
>> 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.

Perhaps, but the maps do need to be zeroed, the partition_tuple_slots
array does not since we only access it when the parent to child map is
set.

In any case, since PARTITION_ROUTING_INITSIZE is just 8, it'll likely
not save much since it's really just saving a memset(..., 0, 64), for
single-row INSERTs on a 64-bit machine. So likely it won't save more
than a bunch of nanoseconds.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: IDE setup and development features?
Next
From: Mark Dilger
Date:
Subject: Re: [HACKERS] removing abstime, reltime, tinterval.c, spi/timetravel