Re: Speeding up INSERTs and UPDATEs to partitioned tables

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Speeding up INSERTs and UPDATEs to partitioned tables
Date: 2018-11-14 20:48:33
Message-ID: CAKJS1f-P7mquSKeqxX7Sfmke24zYGWc_4b1kf3X+SvpifU7GDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for picking this up.

On 15 November 2018 at 07:10, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2018-11-14 21:27:24 Re: In-place updates and serializable transactions
Previous Message Tom Lane 2018-11-14 20:42:31 Re: date_trunc() in a specific time zone