Re: [PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-11 Thread Claudio Freire
On Fri, Jan 11, 2013 at 8:55 PM, Horst Dehmer wrote: > Except - and that's the wall I'm hitting - for one table which yielded just > 75 records/second. > The main 'problem' seem to be the FK constraints. Dropping just them > restored insert performance for this table to 6k records/s. The table in

[PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-11 Thread Jeff Janes
On Friday, January 11, 2013, Horst Dehmer wrote: > > Except - and that's the wall I'm hitting - for one table which yielded > just 75 records/second. > The main 'problem' seem to be the FK constraints. Dropping just them > restored insert performance for this table to 6k records/s. > It sure soun

[PERFORM] Insert performance for large transaction with multiple COPY FROM

2013-01-11 Thread Horst Dehmer
Hi! I see a massive performance drop when writing a large transaction. I'm writing data for 33 tables with COPY FROM directly from streams in Scala/Java. Over all tables there are 2.2M records which are unevenly distributed from 1 record to 315k records in some tables. For comparison I ran a t

Re: [PERFORM] Slow query after upgrade from 9.0 to 9.2

2013-01-11 Thread Jeff Janes
On Fri, Jan 11, 2013 at 12:13 AM, Andrzej Zawadzki wrote: > On 10.01.2013 19:17, Jeff Janes wrote: >> Also, if you temporarily set enable_seqscan=off on 9.2, what plan do >> you then get? > > Plan is different. > > "Join Filter: (sa.arrear_import_id = ai.id)" It is hard to imagi

Re: [PERFORM] Partition insert trigger using C language

2013-01-11 Thread Matheus de Oliveira
On Fri, Jan 11, 2013 at 9:02 AM, Heikki Linnakangas wrote: > On 11.01.2013 12:36, Matheus de Oliveira wrote: > >> On Fri, Jan 11, 2013 at 8:19 AM, Heikki Linnakangas> vmware.com >> >>> wrote: >>> >> >> One thing that caught my eye: >>> >>> CREATE OR REPLACE FUNCTION partition_insert_trigger_s

Re: [PERFORM] Partition insert trigger using C language

2013-01-11 Thread Heikki Linnakangas
On 11.01.2013 12:36, Matheus de Oliveira wrote: On Fri, Jan 11, 2013 at 8:19 AM, Heikki Linnakangas wrote: One thing that caught my eye: CREATE OR REPLACE FUNCTION partition_insert_trigger_spi() RETURNS trigger LANGUAGE C VOLATILE STRICT AS 'partition_insert_trigger_spi'**,'partition_inser

Re: [PERFORM] Partition insert trigger using C language

2013-01-11 Thread Matheus de Oliveira
On Thu, Jan 10, 2013 at 5:51 PM, Charles Gomes < charles.go...@benchmarksolutions.com> wrote: > ** ** > > *From:* pgsql-performance-ow...@postgresql.org [mailto: > pgsql-performance-ow...@postgresql.org] *On Behalf Of *Matheus de Oliveira > *Sent:* Thursday, January 10, 2013 2:12 PM > *To:* Heikk

Re: [PERFORM] Partition insert trigger using C language

2013-01-11 Thread Matheus de Oliveira
On Fri, Jan 11, 2013 at 8:19 AM, Heikki Linnakangas wrote: > On 10.01.2013 21:48, Matheus de Oliveira wrote: > >> I have made a small modification to keep the plans, and it got from >> 33957.768ms to 43782.376ms. >> > > If I'm reading results.txt correctly, the avg runtimes are: > > C and SPI_exe

Re: [PERFORM] Partition insert trigger using C language

2013-01-11 Thread Heikki Linnakangas
On 10.01.2013 21:48, Matheus de Oliveira wrote: I have made a small modification to keep the plans, and it got from 33957.768ms to 43782.376ms. If I'm reading results.txt correctly, the avg runtimes are: C and SPI_execute_with_args: 58567.708 ms C and SPI_(prepare/keepplan/execute_plan): 43782

Re: [PERFORM] Slow query after upgrade from 9.0 to 9.2

2013-01-11 Thread Andrzej Zawadzki
On 10.01.2013 19:48, Matheus de Oliveira wrote: > > > On Thu, Jan 10, 2013 at 11:32 AM, Andrzej Zawadzki > wrote: > > Hi! > > Small query run on 9.0 very fast: > > SELECT * from sygma_arrear sar where sar.arrear_import_id = ( > select sa.arrear_import_

Re: [PERFORM] Slow query after upgrade from 9.0 to 9.2

2013-01-11 Thread Andrzej Zawadzki
On 10.01.2013 19:17, Jeff Janes wrote: > On Thu, Jan 10, 2013 at 5:32 AM, Andrzej Zawadzki wrote: >> Why that's happens? All configurations are identical. Only engine is >> different. > Could you post explain (analyze, buffers) instead of just explain? Impossible, 1h of waiting and I've killed tha