Re: [PERFORM] Two Necessary Kernel Tweaks for Linux Systems

2013-01-10 Thread Henri Philipps
Hi, we also hit this performance barrier a while ago, when migrating a database on a big server (48 core Opteron, 512GB RAM) from Kernel 2.6.32 to 3.2 (both kernels from Debian packages). The system load was getting very high, as you also observed (don't know the exact numbers right now). After

[PERFORM] Slow query after upgrade from 9.0 to 9.2

2013-01-10 Thread Andrzej Zawadzki
Hi! Small query run on 9.0 very fast: SELECT * from sygma_arrear sar where sar.arrear_import_id = ( select sa.arrear_import_id from sygma_arrear sa, arrear_import ai where sa.arrear_flag_id = 2 AND sa.arrear_import_id = ai.id AND ai.import_type_id = 1

Re: [PERFORM] Two Necessary Kernel Tweaks for Linux Systems

2013-01-10 Thread Shaun Thomas
On 01/10/2013 02:51 AM, Henri Philipps wrote: http://research.cs.wisc.edu/adsl/Publications/meehean-thesis11.pdf Wow, that was pretty interesting. It looks like for servers, the O(1) scheduler is much better even with the assignment bug he identified, and BFS responds better to varying load

[PERFORM] Updates on one row causing ExclusiveLock on PostgreSQL 8.3.5

2013-01-10 Thread PostgreSQL
My best regards for all... Please. I need for an advice. I'm having a trouble, that puting others queries in wait state, becouse of ExclusiveLock granted by an Update that only update one row at each time. This update occurs into a function and this function are executed several times and

[PERFORM] Updates on one row causing ExclusiveLock on PostgreSQL 8.3.5

2013-01-10 Thread PostgreSQL
My best regards for all... Please. I need for an advice. I'm having a trouble, that puting others queries in wait state, becouse of ExclusiveLock granted by an Update that only update one row at each time. This update occurs into a function and this function are executed several times and

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

2013-01-10 Thread Jeff Janes
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? Also, if you temporarily set enable_seqscan=off on 9.2, what plan do you

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

2013-01-10 Thread Matheus de Oliveira
On Thu, Jan 10, 2013 at 11:32 AM, Andrzej Zawadzki zawa...@wp.pl wrote: Hi! Small query run on 9.0 very fast: SELECT * from sygma_arrear sar where sar.arrear_import_id = ( select sa.arrear_import_id from sygma_arrear sa, arrear_import ai where sa.arrear_flag_id = 2

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Heikki Linnakangas
On 10.01.2013 20:45, Matheus de Oliveira wrote: Inspired by Charles' thread and the work of Emmanuel [1], I have made some experiments trying to create a trigger to make partitioning using C language. The first attempt was not good, I tried to use SPI [2] to create a query to insert into the

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Matheus de Oliveira
On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 10.01.2013 20:45, Matheus de Oliveira wrote: Inspired by Charles' thread and the work of Emmanuel [1], I have made some experiments trying to create a trigger to make partitioning using C language. The

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Pavel Stehule
2013/1/10 Heikki Linnakangas hlinnakan...@vmware.com: On 10.01.2013 20:45, Matheus de Oliveira wrote: Inspired by Charles' thread and the work of Emmanuel [1], I have made some experiments trying to create a trigger to make partitioning using C language. The first attempt was not good, I

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Heikki Linnakangas
On 10.01.2013 21:11, Matheus de Oliveira wrote: On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangashlinnakan...@vmware.com wrote: The right way to do this with SPI is to prepare each insert-statement on first invocation (SPI_prepare + SPI_keepplan), and reuse the plan after that

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Matheus de Oliveira
On Thu, Jan 10, 2013 at 5:22 PM, Heikki Linnakangas hlinnakan...@vmware.com wrote: On 10.01.2013 21:11, Matheus de Oliveira wrote: On Thu, Jan 10, 2013 at 4:54 PM, Heikki Linnakangashlinnakangas@** vmware.com hlinnakan...@vmware.com wrote: The right way to do this with SPI is to

Re: [PERFORM] Partition insert trigger using C language

2013-01-10 Thread Charles Gomes
From: matioli.math...@gmail.com Date: Thu, 10 Jan 2013 16:45:43 -0200 Subject: Partition insert trigger using C language To: pgsql-performance@postgresql.org CC: charle...@outlook.com Hi All, Inspired by Charles' thread and the work of Emmanuel