[PERFORM] Performance difference between Slon master and slave

Hello all, I hope someone can help me with this. Postgres 9.4.4 Slon 2.2.4 Linux I am using slony-i to replicate a production database which is in the order of 70GB. I have a reasonably complex select query that runs in 40 seconds on the master but takes in the region of 30-40 minutes on the

Re: [PERFORM] Performance problems inside a stored procedure.

Thanks for your help Андрей your English is easily understandable and much better than my ... (Russian?). I managed to get the results of an analyze and this showed that an index was not being used correctly. It seems that I was passing in a varchar and not casting it to an int and this

Re: [PERFORM] JDBC/Stored procedure performance issue

Hi Tom, Is there any way to work out what plan the query is using in side the function? I think I have a similar problem with a query taking much longer from inside a function than it does as a select statement. Regards Matthew Tom Lane wrote: Claire McLister [EMAIL PROTECTED] writes:

Re: [PERFORM] Performance problems inside a stored procedure.

Oliveira wrote: Matthew Lunnon wrote: Ahh, sorry, I have been too aggressive with my cutting, I am running 8.2.6 and the function is below. snip $BODY$ LANGUAGE 'sql' VOLATILE; ^^ I suspect that it's because you're using VOLATILE (so no good optimizations is done

[PERFORM] Performance issues migrating from 743 to 826

Hi I am investigating migrating from postgres 743 to postgres 826 but although the performance in postgres 826 seems to be generally better there are some instances where it seems to be markedly worse, a factor of up to 10. The problem seems to occur when I join to more than 4 tables. Has

Re: [PERFORM] Performance problems inside a stored procedure.

'::bpchar AND app.live 'X'::bpchar AND MARKET_ID = $1 AND CODE = $2 AND CODE_TYPE = $3::CHAR(2) AND CONTRACT_ID = $4 AND ( PRICE_PANEL_TYPE = 'B' OR PRICE_PANEL_TYPE = $5 ); $BODY$ LANGUAGE 'sql' VOLATILE; Heikki Linnakangas wrote: Matthew Lunnon wrote: I have a query which runs

[PERFORM] Performance problems inside a stored procedure.

Hi ms I have a query which runs pretty quick ( 0.82ms) but when I put it inside a stored procedure it takes 10 times as long (11.229ms). Is this what you would expect and is there any way that I can get around this time delay? postgres.conf changes. shared_buffers = 500MB work_mem = 10MB

Re: [PERFORM] Performance issues migrating from 743 to 826

using Thunderbird, maybe I need to upgrade. On Jan 28, 2008 9:27 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: Scott Marlowe wrote: On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: default_statistics_target = 1000 That's very high for the default. Planning times

Re: [PERFORM] Performance issues migrating from 743 to 826

Hi Scott, Thanks for your time Regards Matthew Scott Marlowe wrote: On Jan 28, 2008 5:41 AM, Matthew Lunnon [EMAIL PROTECTED] wrote: Hi I am investigating migrating from postgres 743 to postgres 826 but although the performance in postgres 826 seems to be generally better there are some

Re: [PERFORM] Performance issues migrating from 743 to 826

ms Gregory Stark wrote: Matthew Lunnon [EMAIL PROTECTED] writes: In this case the query takes 6.037 ms to run on 862 and 2.332 to run on 743. The difference between 2ms and 6ms is pretty negligable. A single context switch or disk cache miss could throw the results off by that margin

[PERFORM] Limited performance on multi core server

Hi, I have a 4 * dual core 64bit AMD OPTERON server with 16G of RAM, running postgres 7.4.3. This has been recompiled on the server for 64 stored procedure parameters, (I assume this makes postgres 64 bit but are not sure). When the server gets under load from database connections

Re: [PERFORM] Limited performance on multi core server

of concurrent queries to less than 8 (8 cores) if you need to stay with Pg 7.4. The memory setting is looking good to me. I would increase sort_mem and effective_cache_size, but this would solve your problem. Best regards Sven. Matthew Lunnon schrieb: Hi, I have a 4 * dual core 64bit AMD OPTERON

Re: [PERFORM] Limited performance on multi core server

. effective_cache_size should also be lowered to something like 32768. As far as I understand shared_buffers and effective_cache_size have to be altered in reverse, ie. when lowering one the other can be raised. HTH. -- Matthew Lunnon Technical Consultant RWA Ltd. [EMAIL PROTECTED] Tel: +44 (0)29 2081 5056

Re: [PERFORM] Limited performance on multi core server

Ah I was afraid of that. Maybe I'll have to come out of the dark ages. Matthew Steinar H. Gunderson wrote: On Wed, Dec 12, 2007 at 10:16:43AM +, Matthew Lunnon wrote: Does anyone have any ideas what my bottle neck might be and what I can do about it? Your bottleneck is that you

Re: [PERFORM] Limited performance on multi core server

PostgreSQL. But if you can upgrade you should upgrade to Pg 8.2.5 64-bit. The scale up for your concurrent queries will be great. Sven. Matthew Lunnon schrieb: Hi, I have a 4 * dual core 64bit AMD OPTERON server with 16G of RAM, running postgres 7.4.3. This has been recompiled on the server

Re: [PERFORM] Limited performance on multi core server

are busy. The configuration helps us to solve the performance issue with to much concurrent queries. I assume that you already checked you application and each sql query is necessary and tuned as best as you can. Regards Sven. Matthew Lunnon schrieb: Limiting the queries was our initial

Re: [PERFORM] Limited performance on multi core server

. Sven. Matthew Lunnon schrieb: Hi, I have a 4 * dual core 64bit AMD OPTERON server with 16G of RAM, running postgres 7.4.3. This has been recompiled on the server for 64 stored procedure parameters, (I assume this makes postgres 64 bit but are not sure). When the server gets under load from