Hello there,
I am having performance problem with new DELL server. Actually I have this
two servers
Server A (old - production)
-
2xCPU Six-Core AMD Opteron 2439 SE
64GB RAM
Raid controller Perc6 512MB cache NV
- 2 HD 146GB SAS 15Krpm RAID1 (SO Centos 5.4 y pg_xlog) (XFS no barr
Did you check your read ahead settings (getra)?
Mike DelNegro
Sent from my iPhone
On Apr 3, 2012, at 8:20 AM, Cesar Martin wrote:
> Hello there,
>
> I am having performance problem with new DELL server. Actually I have this
> two servers
>
> Server A (old - production)
> -
>
Hi Mike,
Thank you for your fast response.
blockdev --getra /dev/sdc
256
What value do you recommend for this setting?
Thanks!
El 3 de abril de 2012 14:37, Mike DelNegro escribió:
> Did you check your read ahead settings (getra)?
>
> Mike DelNegro
>
> Sent from my iPhone
>
> On Apr 3, 2012, a
On Tue, Apr 3, 2012 at 7:20 AM, Cesar Martin wrote:
> Hello there,
>
> I am having performance problem with new DELL server. Actually I have this
> two servers
>
> Server A (old - production)
> -
> 2xCPU Six-Core AMD Opteron 2439 SE
> 64GB RAM
> Raid controller Perc6 512MB cache NV
On 3.4.2012 14:59, Cesar Martin wrote:
> Hi Mike,
> Thank you for your fast response.
>
> blockdev --getra /dev/sdc
> 256
That's way too low. Is this setting the same on both machines?
Anyway, set it to 4096, 8192 or even 16384 and check the difference.
BTW explain analyze is nice, but it's onl
On Wed, Feb 29, 2012 at 3:37 PM, Igor Schtein wrote:
> Do you see any performance difference between the following approaches? The
> assumption is that most of the rows in the query will be requested often
> enough.
>
>
>
> 1. SQL function.
>
> CREATE OR REPLACE FUNCTION X(IN a_id uuid, IN b
On 04/03/2012 10:21 AM, Robert Haas wrote:
You should probably test this in your environment, but I'd expect the
view to be better. Wrapping logic inside PL/pgsql functions
needlessly rarely turn outs to be a win.
Right, But also note that auto_explain is very useful in getting plans
and
On Sat, Mar 3, 2012 at 10:03 PM, Tom Lane wrote:
> Claus Stadler writes:
>> Query optimizer glitch: "...WHERE TRUE" condition in union results in
>> bad query plan ...
>
> Yeah, this is because a nonempty WHERE clause defeats simplifying the
> UNION ALL into a simple "append relation" (cf is_safe
On Sun, Apr 2, 2012 at 11:25 AM, Samuel Gendler < sgend...@ideasculptor.com >
wrote:
> But suggesting moving away from TCP/IP with no actual evidence that it is
> network overhead that is the problem is a little premature, regardless.
Agreed, that's why I'd like to understand what tools / met
On Tue, Apr 3, 2012 at 6:20 AM, Cesar Martin wrote:
> Hello there,
>
> I am having performance problem with new DELL server. Actually I have this
> two servers
>
> Server A (old - production)
> -
> 2xCPU Six-Core AMD Opteron 2439 SE
> 64GB RAM
> Raid controller Perc6 512MB cache NV
On Tue, Apr 3, 2012 at 9:32 AM, Scott Marlowe wrote:
> On Tue, Apr 3, 2012 at 6:20 AM, Cesar Martin wrote:
>> Hello there,
>>
>> I am having performance problem with new DELL server. Actually I have this
>> two servers
>>
>> Server A (old - production)
>> -
>> 2xCPU Six-Core AMD O
Robert Haas writes:
> On Sat, Mar 3, 2012 at 10:03 PM, Tom Lane wrote:
>> Sooner or later I'd like to relax the restriction that appendrel members
>> can't have extra WHERE clauses, but don't hold your breath waiting...
> Does this comment need updating?
> * Note: the data structure assumes th
On Tue, Apr 3, 2012 at 12:24 PM, Ofer Israeli wrote:
> On Sun, Apr 2, 2012 at 11:25 AM, Samuel Gendler < sgend...@ideasculptor.com >
> wrote:
>> But suggesting moving away from TCP/IP with no actual evidence that it is
>> network overhead that is the problem is a little premature, regardless.
>
Yes, setting is the same in both machines.
The results of bonnie++ running without arguments are:
Version 1.96 --Sequential Output-- --Sequential Input-
--Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
MachineSize K/sec %CP K/sec %CP
OK Scott. I go to change this kernel parameter and will repeat the tests.
Tanks!
El 3 de abril de 2012 17:34, Scott Marlowe escribió:
> On Tue, Apr 3, 2012 at 9:32 AM, Scott Marlowe
> wrote:
> > On Tue, Apr 3, 2012 at 6:20 AM, Cesar Martin wrote:
> >> Hello there,
> >>
> >> I am having performa
OK Scott. I go to change this kernel parameter and will repeat the tests.
Tanks!
El 3 de abril de 2012 17:34, Scott Marlowe escribió:
> On Tue, Apr 3, 2012 at 9:32 AM, Scott Marlowe
> wrote:
> > On Tue, Apr 3, 2012 at 6:20 AM, Cesar Martin wrote:
> >> Hello there,
> >>
> >> I am having performa
On Tue, Apr 3, 2012 at 10:38 AM, Claudio Freire wrote:
>
> You perform 8 roundtrips minimum per event, so that's 375us per query.
> It doesn't look like much. That's probably Nagle and task switching
> time, I don't think you can get it much lower than that, without
> issuing less queries (ie: usi
Hi All;
I have a query that wants to update a table based on a join like this:
update test_one
set f_key = t.f_key
from
upd_temp1 t,
test_one t2
where
t.id_number = t2.id_number
upd_temp1 has 248,762 rows
test_one has 248,762 rows
test_one has an index on f_key and an index on id_n
Kevin Kempter wrote:
> update test_one
> set f_key = t.f_key
> from
> upd_temp1 t,
> test_one t2
> where
> t.id_number = t2.id_number
As written above, it is joining the two table references in the FROM
clause and updating every row in test_one with every row in the JOIN
-- whic
On 04/03/2012 01:29 PM, Kevin Kempter wrote:
Hi All;
I have a query that wants to update a table based on a join like this:
update test_one
set f_key = t.f_key
from
upd_temp1 t,
test_one t2
where
t.id_number = t2.id_number
Why is test_one in the from clause? update joins whatev
Andrew Dunstan wrote:
> Why is test_one in the from clause? update joins whatever is in
> the from clause to the table being updated. You almost never need
> it repeated in the from clause.
This is actually one of the nastier "gotchas" in converting from
Sybase ASE or MS SQL Server to PostgreS
Kevin Kempter wrote on 03.04.2012 19:29:
Hi All;
I have a query that wants to update a table based on a join like this:
update test_one
set f_key = t.f_key
from
upd_temp1 t,
test_one t2
where
t.id_number = t2.id_number
upd_temp1 has 248,762 rows
test_one has 248,762 rows
To extend on what K
On 3.4.2012 17:42, Cesar Martin wrote:
> Yes, setting is the same in both machines.
>
> The results of bonnie++ running without arguments are:
>
> Version 1.96 --Sequential Output-- --Sequential Input-
> --Random-
> -Per Chr- --Block-- -Rewrite- -Per Chr- --Blo
On Tue, Apr 3, 2012 at 1:01 PM, Tomas Vondra wrote:
> On 3.4.2012 17:42, Cesar Martin wrote:
>> Yes, setting is the same in both machines.
>>
>> The results of bonnie++ running without arguments are:
>>
>> Version 1.96 --Sequential Output-- --Sequential Input-
>> --Random-
>>
On Tue, Apr 3, 2012 at 12:29 PM, Kevin Kempter
wrote:
> Hi All;
>
> I have a query that wants to update a table based on a join like this:
>
> update test_one
> set f_key = t.f_key
> from
> upd_temp1 t,
> test_one t2
> where
> t.id_number = t2.id_number
>
> upd_temp1 has 248,762 rows
> te
Howdy,
What is/is there a replacement for pg_autovacuum in PG9.0+ ?
I haven't had much luck looking for it in the docs.
Thanks!
Dave
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-p
On 04/03/2012 06:40 PM, Brett Mc Bride wrote:
> Hi Dave,
> It's part of core now: http://www.postgresql.org/docs/9.1/static
/routine-vacuuming.html#AUTOVACUUM
AH awesome, thanks.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription
27 matches
Mail list logo
