Re: [PERFORM] Determining server load from client

2007-03-20 Thread Jim Buttafuoco
Dan Use the following plperlu function create or replace function LoadAVG() returns record as $$ use Sys::Statistics::Linux::LoadAVG; my $lxs = new Sys::Statistics::Linux::LoadAVG; my $stats = $lxs->get; return $stats; $$ language plperlu; select * from LoadAVg() as (avg_1 float,avg_5 float,av

Re: [PERFORM] Better way to write aggregates?

2006-04-21 Thread Jim Buttafuoco
I don't think an index will help you with this query. -- Original Message --- From: Jan Dittmer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: pgsql-performance@postgresql.org Sent: Fri, 21 Apr 2006 14:35:33 +0200 Subject: Re: [PERFORM] Better way to write aggrega

Re: [PERFORM] Better way to write aggregates?

2006-04-21 Thread Jim Buttafuoco
Jan, I write queries like this CREATE VIEW parent_childs AS SELECT c.parent, count(c.state) as childtotal, sum(case when c.state = 1 then 1 else 0 end) as childstate1, sum(case when c.state = 2 then 1 else 0 end) as childstate2, sum(case when c.state = 3 t

Re: [PERFORM] Quick Performance Poll

2006-04-20 Thread Jim Buttafuoco
lt;[EMAIL PROTECTED]>, pgsql-performance@postgresql.org Sent: Thu, 20 Apr 2006 08:03:10 -0700 Subject: Re: [PERFORM] Quick Performance Poll > Jim, > > On 4/20/06 7:40 AM, "Jim Buttafuoco" <[EMAIL PROTECTED]> wrote: > > > First of all this is NOT a single tab

Re: [PERFORM] Quick Performance Poll

2006-04-20 Thread Jim Buttafuoco
rformance Poll > Jim, > > On 4/20/06 6:36 AM, "Jim Buttafuoco" <[EMAIL PROTECTED]> wrote: > > > The access is very fast when looking for a small subset of the data. > > I guess you are not using indexes because building a (non bitmap) index on > 6TB on a

Re: [PERFORM] Quick Performance Poll

2006-04-20 Thread Jim Buttafuoco
Simon, I have many databases over 1T with the largest being ~6T. All of my databases store telecom data, such as call detail records. The access is very fast when looking for a small subset of the data. For servers, I am using white box intel XEON and P4 systems with SATA disks, 4G of memory

Re: [PERFORM] update == delete + insert?

2006-03-20 Thread Jim Buttafuoco
go with design 1, update does = delete + insert. -- Original Message --- From: "Craig A. James" <[EMAIL PROTECTED]> To: pgsql-performance@postgresql.org Sent: Mon, 20 Mar 2006 14:49:43 -0800 Subject: [PERFORM] update == delete + insert? > I've seen it said here several times that

Re: [PERFORM] Query planner issue

2006-01-30 Thread Jim Buttafuoco
with Postgresql 7.2.1 you will need to do BOTH vacuum and reindex and with a table that gets many updates/deletes, you should run vacuum more than daily. Both issues have been solved in 8.1. Jim -- Original Message --- From: Emmanuel Lacour <[EMAIL PROTECTED]> To: pgsql-perfo

Re: [PERFORM] Stored Procedure

2005-11-22 Thread Jim Buttafuoco
create function abc() returns setof RECORD ... then to call it you would do select * from abc() as (a text,b int,...); -- Original Message --- From: Yves Vindevogel <[EMAIL PROTECTED]> To: pgsql-performance@postgresql.org Sent: Tue, 22 Nov 2005 19:29:37 +0100 Subject: [PERFORM]

Re: [PERFORM] Postgres on RAID5

2005-03-14 Thread Jim Buttafuoco
All, I have a 13 disk (250G each) software raid 5 set using 1 16 port adaptec SATA controller. I am very happy with the performance. The reason I went with the 13 disk raid 5 set was for the space NOT performance. I have a single postgresql database that is over 2 TB with about 500 GB free