Re: [PERFORM] New server setup

On 10 March 2013 15:58, Greg Smith wrote: > On 3/1/13 6:43 AM, Niels Kristian Schjødt wrote: > >> Hi, I'm going to setup a new server for my postgresql database, and I am >> considering one of these: http://www.hetzner.de/hosting/** >> produkte_rootserver/poweredge-**r720

Re: [PERFORM] PostgreSQL 9.2.3 performance problem caused Exclusive locks

2013-03-08 13:27:16 +0200 Emre Hasegeli : PostgreSQL writes several following logs during the problem which I never saw before 9.2.3: LOG: process 4793 acquired ExclusiveLock on extension of relation 305605 of database 16396 after 2348.675 ms I tried * to downgrade to 9.2.2 * to disable a

Re: [PERFORM] Slow concurrent processing

:( Ah - 9.1.0 is postgres version on Ubuntu... Thanks Jeff - you saved me some time - reorganising functions to work with different tables would take time... what potentially will not give us solution :( Many thanks, Misa 2013/3/12 Jeff Janes > On Tue, Mar 12, 2013 at 7:13 AM, Misa Simic w

Re: [PERFORM] Slow concurrent processing

Thanks Steve, Of course I thought under the limits... I haven't thought there are that kind of problems(CPU/Memory/io) because of there are no degradation during long running process - on other sides... i.e. some complex query - run when long running process is off and run it when long runing pro

Re: [PERFORM] Slow concurrent processing

On Tue, Mar 12, 2013 at 7:13 AM, Misa Simic wrote: > Hi, > > Researching deeply my problem with concurrent processing i have found: > > > http://postgresql.1045698.n5.nabble.com/WHY-transaction-waits-for-another-transaction-tp2142627p2142630.html > > > "The more likely suspect is a foreign key co

Re: [PERFORM] Slow concurrent processing

On 03/12/2013 08:06 AM, Misa Simic wrote: Thanks Steve Well, the full story is too complex - but point was - whatever blackbox does - it last 0.5 to 2secs per 1 processed record (maybe I was wrong but I thought the reason why it takes the time how much it needs to actually do the task -CPU/IO

Re: [PERFORM] Slow concurrent processing

Thanks Steve Well, the full story is too complex - but point was - whatever blackbox does - it last 0.5 to 2secs per 1 processed record (maybe I was wrong but I thought the reason why it takes the time how much it needs to actually do the task -CPU/IO/memory whatever is not that important) - s

Re: [PERFORM] Slow concurrent processing

On 03/11/2013 08:55 PM, Misa Simic wrote: Hi all, We have one table with list of "records for processing"... We loop trough that table and call one long runing function: do_the_math_for_record(record_id).. but - if replace do_the_math_and_save_results with pg_sleep(1); To simulate long

Re: [PERFORM] Slow concurrent processing

Hi, Researching deeply my problem with concurrent processing i have found: http://postgresql.1045698.n5.nabble.com/WHY-transaction-waits-for-another-transaction-tp2142627p2142630.html "The more likely suspect is a foreign key conflict. Are both transactions inserting/updating rows that could re

Re: [PERFORM] Slow query when used in a view

On 03/11/2013 06:56 PM, Tom Lane wrote: And that means that you get the inefficient plan wherein the foo-to-tiny_foo join is computed in its entirety. :( That's unfortunate, though I guess it makes sense. I moved the join in the view into the SELECT clause as an EXISTS, and that seems to wor

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

2013/3/11 Jeff Adams - NOAA Affiliate > Greetings, > > > > I have a large table (~90 million rows) containing vessel positions. > > > ... > > > Could you kindly provide a script to create the table and populate it with several sample rows, please? Also, provide the desired output for the sample

Re: [PERFORM] Large Table - Slow Window Functions (Better Approach?)

So, I tested out the cursor approach, and it still chugs along for hours. If the result set is large (and the available memory to process small), does it matter what goes on within the cursor. Will it still choke trying assemble and spit out the large result set? On Mon, Mar 11, 2013 at 11:48 AM,