On 9 November 2018 at 18:45, Amit Langote wrote:
> As long as queries involve tuple routing that touches multiple not yet
> seen partitions, someone doing conflicting operations directly on multiple
> partitions in a transaction will have to be ready to see deadlocks.
> Maybe, we can document that
ge-
> From: David Rowley [mailto:david.row...@2ndquadrant.com]
> Sent: Friday, November 9, 2018 11:20 AM
> To: Kato, Sho/加藤 翔 ; Amit Langote
> ; Robert Haas
> Cc: PostgreSQL Hackers
> Subject: Re: Performance improvements of INSERTs to a partitioned table
>
> On 7 Novem
On 2018/11/09 11:19, David Rowley wrote:
> On 7 November 2018 at 21:31, Kato, Sho wrote:
>> AFAIK, When CREATE INDEX on a partition and INSERT to a parent table are
>> executed at the same time, this patch causes deadlock.
>>
>> * partitions information
>>
>> Partition key: RANGE (a)
>> Partitions
On 7 November 2018 at 21:31, Kato, Sho wrote:
> AFAIK, When CREATE INDEX on a partition and INSERT to a parent table are
> executed at the same time, this patch causes deadlock.
>
> * partitions information
>
> Partition key: RANGE (a)
> Partitions: a_1 FOR VALUES FROM (1) TO (100),
>
ioned table
Hi,
I want to discuss performance improvements of INSERTs to a partitioned table.
When an application inserts records into a table partitioned into thousands,
find_all_inheritors() locks all of the partitions.
Updating partition key locks in the same way.
So, Execution time becomes l
Hi,
I want to discuss performance improvements of INSERTs to a partitioned table.
When an application inserts records into a table partitioned into thousands,
find_all_inheritors() locks all of the partitions.
Updating partition key locks in the same way.
So, Execution time becomes longer as
