Re: [PERFORM] Bad prepare performance

2008-04-01 Thread Cédric Villemain
Hi Martin, please CC the mailing-list, then others can repply ;) Cédric Villemain (13:59 2008-03-31): Le Monday 31 March 2008, Martin Kjeldsen a écrit : I've done the same query on a 8.2.5 database. The first one is prepared first and the other is executed directly. I understand why the

[PERFORM] check performance parameters

2008-04-01 Thread Sabin Coanda
Hi there, I have an application accessing a postgres database, and I need to estimate the following parameters: - read / write ratio - reads/second on typical load / peak load - writes/second on typical load / peak load Is there any available tool to achieve that ? TIA, Sabin -- Sent via

[PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Hell, Robert
Hi, the following statement retrieves 16358 rows in a cursor by fetching 1024 rows in bulks on a 8.2.4 server: DECLARE curs_285058224 CURSOR FOR SELECT objid, attrid, aggrid, lineid, objval FROM atobjval WHERE objid IN (281479288456304,281479288456359,281479288456360,281479288456384,2814792

Re: [PERFORM] check performance parameters

2008-04-01 Thread Matthew
On Tue, 1 Apr 2008, Sabin Coanda wrote: I have an application accessing a postgres database, and I need to estimate the following parameters: - read / write ratio - reads/second on typical load / peak load - writes/second on typical load / peak load Is there any available tool to achieve that

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Tom Lane
Hell, Robert [EMAIL PROTECTED] writes: When we use 20 as default_statistics_target the retrieval of the data takes 7.5 seconds - with 25 as default_statistics_target (with restart and analyze) it takes 0.6 seconds. The query plan is identical in both situations (row estimation differs a

[PERFORM] Insert time

2008-04-01 Thread Ioana Danes
Hi everyone, I am running a test with 1 thread calling a stored procedure in an endless loop. The stored procedure inserts 1000 records in a table that does not have indexes or constraints. In the log file I see that the time to execute the procedure sometimes it jumps from 100 ms to 700 ms. The

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Hell, Robert
That's it - I found a more simple statement which has the same problem (0.02 seconds vs. 6 seconds): With cursor (6 seconds): appcooelakdb2= explain DECLARE curs_1 CURSOR FOR SELECT DISTINCT t2.objid FROM atobjval t2 WHERE t2.aggrid = 0 AND t2.attrid = 281479288455385 ORDER BY t2.objid;

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Tom Lane
Hell, Robert [EMAIL PROTECTED] writes: That's it - I found a more simple statement which has the same problem (0.02 seconds vs. 6 seconds): This isn't necessarily the very same problem --- what are the plans for your original case with the two different stats settings? What's the difference

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Hell, Robert
Here are the query plans for the original query - looks very similar (to me): EXPLAIN SELECT objid, attrid, aggrid, lineid, objval FROM atobjval WHERE objid IN (281479288456304,many of them,285774255837674) ORDER BY objid, attrid, aggrid, lineid; QUERY

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Tom Lane
Hell, Robert [EMAIL PROTECTED] writes: That's CURSOR_OPT_FAST_PLAN and isn't it? Our application reads the full results of most cursors. Just out of curiosity, why use a cursor at all then? But anyway, you might want to consider running a custom build with a higher setting for tuple_fraction

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Steinar H. Gunderson
On Tue, Apr 01, 2008 at 12:42:03PM -0400, Tom Lane wrote: That's CURSOR_OPT_FAST_PLAN and isn't it? Our application reads the full results of most cursors. Just out of curiosity, why use a cursor at all then? This isn't the same scenario as the OP, but I've used a cursor in cases where I

[PERFORM] Too many commands in a transaction

2008-04-01 Thread samantha mahindrakar
Hi Iam getting the below error when iam running my program. ERROR: cannot have more than 2^32-1 commands in a transaction SQL state: 54000 If iam not wrong this error ocuurs when there are too many statements executing in one single transaction. But this error is occuring in a function that iam

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Hell, Robert
Looks much better when using 0.0 for tuple_fraction in case of a cursor instead of 0.1. But why are the first 15 fetches (15360 rows) processed in 0.5 seconds and the last fetch (998 rows) takes 7 seconds. Are we just unlucky that the last fetch takes that long? EXPLAIN SELECT objid, attrid,

Re: [PERFORM] Cursors and different settings for default_statistics_target

2008-04-01 Thread Tom Lane
Hell, Robert [EMAIL PROTECTED] writes: But why are the first 15 fetches (15360 rows) processed in 0.5 seconds and the last fetch (998 rows) takes 7 seconds. Are we just unlucky that the last fetch takes that long? Well, the indexscan plan is going to scan through all the rows in objid order