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 CAKJS1f8MvJUZ4Gj+PDJtkk8tjgt0VR9w4oRfEa93PqTQamP_-w@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
Re: Speeding up INSERTs and UPDATEs to partitioned tables
List pgsql-hackers
Thanks for looking at this again.

On 14 November 2018 at 13:47, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> +    if (dispatchidx >= proute->dispatch_allocsize)
> +    {
> +        /* Expand allocated space. */
> +        proute->dispatch_allocsize *= 2;
> +        proute->partition_dispatch_info = (PartitionDispatchData **)
> +            repalloc(proute->partition_dispatch_info,
> +                     sizeof(PartitionDispatchData *) *
> +                     proute->dispatch_allocsize);
> +    }
>
> Sorry, I forgot to point this out before, but can this code in
> ExecInitPartitionDispatchInfo be accommodated in
> ExecCheckPartitionArraySpace() for consistency?

I don't really want to put that code in ExecCheckPartitionArraySpace()
as the way the function is now, it makes quite a lot of sense for the
compiler to inline it. If we add redundant work in there, then it
makes less sense.  There's never any need to check both arrays at once
as we're only adding the new item to one array at a time.

Instead, I've written a new function named
ExecCheckDispatchArraySpace() and put the resize code inside that.

I've fixed the typos you mentioned. The only other thing I changed was
to only allocate the PartitionDispatch->tupslot if a conversion is
required.  The previous code allocated this regardless if it was going
to be used or not.  This saves both the redundant allocation and also
very slightly reduces the cost of the if test in ExecFindPartition().
There's now no need to check if the map ! NULL as if the slot is there
then the map must exist too.

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

Attachment

pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Amit Langote
Date:
Subject: Re: Speeding up INSERTs and UPDATEs to partitioned tables