On 10.01.2013 19:17, Jeff Janes wrote:
On Thu, Jan 10, 2013 at 5:32 AM, Andrzej Zawadzki zawa...@wp.pl 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
On 10.01.2013 19:48, Matheus de Oliveira wrote:
On Thu, Jan 10, 2013 at 11:32 AM, Andrzej Zawadzki zawa...@wp.pl
mailto:zawa...@wp.pl wrote:
Hi!
Small query run on 9.0 very fast:
SELECT * from sygma_arrear sar where sar.arrear_import_id = (
select
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):
On Fri, Jan 11, 2013 at 8:19 AM, Heikki Linnakangas hlinnakan...@vmware.com
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:
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:* Heikki
On Fri, Jan 11, 2013 at 9:02 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 11.01.2013 12:36, Matheus de Oliveira wrote:
On Fri, Jan 11, 2013 at 8:19 AM, Heikki Linnakangashlinnakangas@**
vmware.com hlinnakan...@vmware.com
wrote:
One thing that caught my eye:
CREATE OR
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
On Fri, Jan 11, 2013 at 8:55 PM, Horst Dehmer horst.deh...@gmail.com 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
