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 CAKJS1f-P7mquSKeqxX7Sfmke24zYGWc_4b1kf3X+SvpifU7GDA@mail.gmail.com
Whole thread Raw
In response to Re: Speeding up INSERTs and UPDATEs to partitioned tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Speeding up INSERTs and UPDATEs to partitioned tables  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Thanks for picking this up.

On 15 November 2018 at 07:10, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> What's with this comment?
>
>          * Initially we must only set up 1 PartitionDispatch object; the one for
>          * the partitioned table that's the target of the command.  If we must
>          * route a tuple via some sub-partitioned table, then its
>          * PartitionDispatch is only built the first time it's required.
>
> You're setting the allocsize to PARTITION_ROUTING_INITSIZE, which is at
> odds with the '1' mentioned in the comment.  Which is wrong?

I don't think either is wrong, but I guess something must be
misleading, so could perhaps be improved.

We're simply allocating enough space for PARTITION_ROUTING_INITSIZE
but we're only initialising 1 item. That leaves space for
PARTITION_ROUTING_INITSIZE - 1 more items before we'd need to
reallocate the array.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: date_trunc() in a specific time zone
Next
From: Kevin Grittner
Date:
Subject: Re: In-place updates and serializable transactions