Re: [PERFORM] WAL logging of SELECT ... INTO command

2006-04-21 Thread Simon Riggs
On Fri, 2006-04-21 at 19:56 -0400, Bruce Momjian wrote: > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers reviews > and approves it. This patch shou

Re: [PERFORM] WAL logging of SELECT ... INTO command

2006-04-21 Thread Bruce Momjian
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Kr

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

2006-04-21 Thread Mikael Carneholm
Your numbers seem quite ok considering the number of disks. We also get a 256Mb battery backed cache module with it, so I'm looking forward to testing the write performance (first using ext3, then xfs). If I get the enough time to test it, I'll test both raid 0+1 and raid 5 configurations although

Re: [PERFORM] Introducing a new linux readahead framework

2006-04-21 Thread Jim C. Nasby
On Fri, Apr 21, 2006 at 08:20:28PM +0800, Wu Fengguang wrote: > Hi Markus, > > On Fri, Apr 21, 2006 at 09:53:34AM +0200, Markus Schaber wrote: > > Are there any rough estimates when this will get into mainline kernel > > (if you intend to submit)? > > I'm not quite sure :) > > The patch itself h

Re: [PERFORM] Takes too long to fetch the data from database

2006-04-21 Thread Jim C. Nasby
On Fri, Apr 21, 2006 at 09:44:25AM -0400, Merlin Moncure wrote: > 2nd 50: > select * from t where j >= j1 and (j > j1 or k > k1) order by j, k limit 50; > 3 fields: > select * from t where i >= i1 and (i > i1 or j >= j1) and (i > i1 or j > > k1 or k > k1) order by i,j,k limit 50; Note that in 8.2

Re: [PERFORM] Takes too long to fetch the data from database

2006-04-21 Thread Bruno Wolff III
On Fri, Apr 21, 2006 at 10:12:24 +0530, soni de <[EMAIL PROTECTED]> wrote: > I don't want to query exactly 81900 rows into set. I just want to fetch 50 > or 100 rows at a time in a decreasing order of stime.(i.e 50 or 100 rows > starting from last to end). You can do this efficiently, if stime h

Re: [PERFORM] Inactive memory Grows unlimited

2006-04-21 Thread Alvaro Herrera
ALVARO ARCILA wrote: > Hi, > > I hope you can help me...there's something wrong going on my db server (OS. > GNU/linux White box)... here's the problem... > > The amount of Inactive memory Grows unlimited this happens only when > Postgresql (8.1.1) is running... after a few days it "eats"

[PERFORM] Inactive memory Grows unlimited

2006-04-21 Thread ALVARO ARCILA
Hi, I hope you can help me...there's something wrong going on my db server (OS. GNU/linux White box)... here's the problem... The amount of Inactive memory Grows unlimited this happens only when Postgresql (8.1.1) is running... after a few days it "eats" all the RAM memory ... so I've h

Re: [PERFORM] Hardware: HP StorageWorks MSA 1500

2006-04-21 Thread Alex Hayward
On Thu, 20 Apr 2006, Mikael Carneholm wrote: > We're going to get one for evaluation next week (equipped with dual > 2Gbit HBA:s and 2x14 disks, iirc). Anyone with experience from them, > performance wise? We (Seatbooker) use one. It works well enough. Here's a sample bonnie output:

Re: [PERFORM] Better way to write aggregates?

2006-04-21 Thread Tom Lane
Jan Dittmer <[EMAIL PROTECTED]> writes: > It would help if booleans could be casted to integer 1/0 :-) As of 8.1 there is such a cast in the system: regression=# select 't'::bool::int; int4 -- 1 (1 row) In earlier releases you can make your own. As for the original question, though: ha

Re: [PERFORM] Little use of CPU ( < 5%)

2006-04-21 Thread Dave Dutcher
Maybe you could post the query and an EXPLAIN ANALYZE of the query. That would give more information for trying to decide what is wrong.   So your question is basically why you get a slower read rate on this query than on other queries?  If I had to guess, maybe it could be that you are s

Re: [PERFORM] Takes too long to fetch the data from database

2006-04-21 Thread Merlin Moncure
On 4/21/06, soni de <[EMAIL PROTECTED]> wrote: > > I don't want to query exactly 81900 rows into set. I just want to fetch 50 > or 100 rows at a time in a decreasing order of stime.(i.e 50 or 100 rows > starting from last to end). aha! you need to implement a 'sliding window' query. simplest is

Re: [PERFORM] Takes too long to fetch the data from database

2006-04-21 Thread Dave Dutcher
I’ve never used a cursor in Postgres, but I don’t think it will help you a lot.  In theory cursors make it easier to do paging, but your main problem is that getting the first page is slow.  A cursor isn’t going to be any faster at getting the first page than OFFSET/LIMIT is.   Did you tr

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 aggregates? > Jim Butta

Re: [PERFORM] Better way to write aggregates?

2006-04-21 Thread Jan Dittmer
Jim Buttafuoco wrote: 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(

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] Introducing a new linux readahead framework

2006-04-21 Thread Wu Fengguang
Hi Markus, On Fri, Apr 21, 2006 at 09:53:34AM +0200, Markus Schaber wrote: > Are there any rough estimates when this will get into mainline kernel > (if you intend to submit)? I'm not quite sure :) The patch itself has been pretty stable. To get it accepted, we must back it by good benchmarking

[PERFORM] Little use of CPU ( < 5%)

2006-04-21 Thread luchot
Hello ,   I have a problem of performance with a query. I use PostgreSQL 8.1.3.   The distribution of Linux is Red Hat Enterprise Linux ES release 4 (Nahant Update 2) and the server is a bi-processor Xeon 2.4GHz with 1 Go of Ram and the size of the database files is about 60 Go.   The problem is th

[PERFORM] Better way to write aggregates?

2006-04-21 Thread Jan Dittmer
Hi, I more or less often come about the problem of aggregating a child table counting it's different states. The cleanest solution I've come up with so far is: BEGIN; CREATE TABLE parent ( id int not null, name text not null, UNIQUE(id) ); CREATE TABLE child ( na

Re: [PERFORM] Introducing a new linux readahead framework

2006-04-21 Thread Markus Schaber
Hi, Wu, Wu Fengguang wrote: >>>In adaptive readahead, the context based method may be of particular >>>interest to postgresql users. It works by peeking into the file cache >>>and check if there are any history pages present or accessed. In this >>>way it can detect almost all forms of sequential

Re: [PERFORM] Introducing a new linux readahead framework

2006-04-21 Thread Wu Fengguang
On Thu, Apr 20, 2006 at 11:31:47PM -0500, Jim C. Nasby wrote: > > In adaptive readahead, the context based method may be of particular > > interest to postgresql users. It works by peeking into the file cache > > and check if there are any history pages present or accessed. In this > > way it can d