Re: Speeding up INSERTs and UPDATEs to partitioned tables

2018-10-30 Thread Krzysztof Nienartowicz
major regression and we'd have to go back to inheritance based one - which seems the best option for now. Regards, Krzysztof On Tue, Oct 30, 2018 at 1:54 AM Amit Langote wrote: > > On 2018/10/30 8:41, Krzysztof Nienartowicz wrote: > > On Thu, Oct 25, 2018 at 5:58 PM Krzys

Re: Speeding up INSERTs and UPDATEs to partitioned tables

2018-10-29 Thread Krzysztof Nienartowicz
is spent in the convert_tuples_by_name (PG10 version). Thanks On Thu, Oct 25, 2018 at 5:58 PM Krzysztof Nienartowicz wrote: > > On Tue, Oct 23, 2018 at 4:02 AM David Rowley > wrote: > > > > On 23 October 2018 at 11:55, Krzysztof Nienartowicz > > wrote: > > >

Re: Speeding up INSERTs and UPDATEs to partitioned tables

2018-10-25 Thread Krzysztof Nienartowicz
On Tue, Oct 23, 2018 at 4:02 AM David Rowley wrote: > > On 23 October 2018 at 11:55, Krzysztof Nienartowicz > wrote: > > In the end we hacked the code to re-enable triggers on partitioned > > tables and switch off native insert code on partitioned tables. Quite > > h

Re: Speeding up INSERTs and UPDATEs to partitioned tables

2018-10-22 Thread Krzysztof Nienartowicz
/find_all_inheritors looked like dominant and also convert_tuples_by_name but not sure if the last one was not an artifact of perf sampling. Will check the patch 0001, thanks. On Tue, Oct 23, 2018 at 12:36 AM David Rowley wrote: > > On 15 October 2018 at 23:04, Krzysztof Nienartowicz &g

Re: Speeding up INSERTs and UPDATEs to partitioned tables

2018-10-15 Thread Krzysztof Nienartowicz
We see quite prohibitive 5-6x slowdown with native partitioning on in comparison to trigger based in PG9.5. This is clearly visible with highly parallel inserts (Can share flamediagrams comparing the two). This basically excludes native partitioning from being used by us. Do you think your chan