[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 stopped

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

ra de 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. $BODY$ LANGUAGE 'sql' VOLATILE; ^^ I suspect that it's because you're using VOLATILE (so no good op

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 issues migrating from 743 to 826

your time. I'm 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

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

t=0.00..0.27 rows=1 width=81) (actual time=0.003..0.004 rows=1 loops=189)" " Index Cond: (mgpr.market_group_id = mg.market_group_id)" " Filter: (live <> 'X'::bpchar)" " -> Seq Scan on market_group_relation mgr (cost=0.00.

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 ar

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

ive <> 'X'::bpchar AND mg.live <> 'X'::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$ LA

[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

[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 an

Re: [PERFORM] Limited performance on multi core server

l 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 for 64 stored procedure parameters, (I assume this makes postgres 64 bit but are not sure). When the server gets under

Re: [PERFORM] Limited performance on multi core server

rkers 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 in

Re: [PERFORM] Limited performance on multi core server

an compile 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

Re: [PERFORM] Limited performance on multi core server

1024. 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

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 +0000, Matthew Lunnon wrote: Does anyone have any ideas what my bottle neck might be and what I can do about it? Your bottleneck is tha

Re: [PERFORM] Limited performance on multi core server

t the number 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 64

[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 executing