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

From Amit Langote
Subject Re: Speeding up INSERTs and UPDATEs to partitioned tables
Date
Msg-id caf396ed-31f0-5cb7-67f6-f1a0bfd9cca0@lab.ntt.co.jp
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
On 2018/11/15 8:58, Alvaro Herrera wrote:
> On 2018-Nov-15, David Rowley wrote:
> 
>> 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.
> 
> Ah, that makes sense.  Yeah, it seems a bit misleading to me.  No
> worries.

Maybe name it PARTITION_INIT_ALLOCSIZE (dropping the ROUTING from it), or
PROUTE_INIT_ALLOCSIZE, to make it clear that it's only allocation size?

Thanks,
Amit



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL Limits and lack of documentation about them.
Next
From: Michael Paquier
Date:
Subject: Re: ATTACH/DETACH PARTITION CONCURRENTLY