RE: speeding up planning with partitions - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: speeding up planning with partitions
Date
Msg-id 0A3221C70F24FB45833433255569204D1FAA4322@G01JPEXMBYT05
Whole thread Raw
In response to speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: speeding up planning with partitions
List pgsql-hackers
From: Amit Langote [mailto:Langote_Amit_f8@lab.ntt.co.jp]
> I measured the gain in performance due to each patch on a modest virtual
> machine.  Details of the measurement and results follow.

Amazing!

UPDATE
> nparts  master    0001   0002   0003
> ======  ======    ====   ====   ====
> 0         2856    2893   2862   2816
> 8          507    1115   1447   1872

SELECT
> nparts  master    0001   0002   0003
> ======  ======    ====   ====   ====
> 0         2290    2329   2319   2268
> 8         1058    1077   1414   1788

Even a small number of partitions still introduces a not-small overhead (UPDATE:34%, SELECT:22%).  Do you think this
overheadcan be reduced further?  What part do you guess would be relevant?  This one?
 


> that it is now performed after pruning. However, it doesn't do anything
> about the fact that partitions are all still locked in the earlier phase.


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Chapman Flack
Date:
Subject: Re: Use C99 designated initializers for some structs
Next
From: Amit Langote
Date:
Subject: Re: speeding up planning with partitions