Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Chris Browne
[EMAIL PROTECTED] ("Joshua D. Drake") writes: > There is a huge advantage to software raid on all kinds of > levels. If you have the CPU then I suggest it. However you will > never get the performance out of software raid on the high level > (think 1 gig of cache) that you would on a software raid

Re: [PERFORM] tsearch2 seem very slow

2005-09-25 Thread Ahmad Fajar
Hi Oleg, Thanks, I will read your documentation again, and try to understand what I miss. And about pgmanual, it is very help me. I'll take attention on that. Regards, ahmad fajar -Original Message- From: Oleg Bartunov [mailto:[EMAIL PROTECTED] Sent: Monday, September 26, 2005 3:12 AM T

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Steinar H. Gunderson
On Sun, Sep 25, 2005 at 06:53:57PM +0200, PFC wrote: > Gonna investigate now if Linux software RAID5 is rugged enough. Can > always buy the a card later if not. Note that 2.6.13 and 2.6.14 have several improvements to the software RAID code, some with regard to ruggedness. You might want t

Re: [PERFORM] tsearch2 seem very slow

2005-09-25 Thread Oleg Bartunov
Ahmad, On Mon, 26 Sep 2005, Ahmad Fajar wrote: Hi Oleg, what king of garbage ? Probably you index not needed token types, for example, email address, file names do you need proximity ? If no, use strip(tsvector) function to remove coordinate information from tsvector. I need proximit

Re: [PERFORM] tsearch2 seem very slow

2005-09-25 Thread Ahmad Fajar
Hi Oleg, > what king of garbage ? Probably you index not needed token types, for > example, email address, file names > do you need proximity ? If no, use strip(tsvector) function to remove > coordinate information from tsvector. I need proximity. Some time I have to rank my article and mak

[PERFORM] Query seem to slow if table have more than 200 million rows

2005-09-25 Thread Ahmad Fajar
If I do a simple query like: Select ids, keywords from dict where keywords='blabla' ('blabla' is a single word); The table have 200 million rows, I have index the keywords field. On the first time my query seem to slow to get the result, about 15-60 sec to get the result. But if I repeat

Re: [PERFORM] tsearch2 seem very slow

2005-09-25 Thread Oleg Bartunov
On Mon, 26 Sep 2005, Ahmad Fajar wrote: Hi Oleg, Sorry for my late. From the stat() function I got 1,5 million rows, although I've added garbage words to the stop word file, there seem still have garbage words. So I ask for my team to identify the garbage words and add to what king of garbage

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Luke Lonergan
>> Even for RAID5 ? it uses a bit more CPU for the parity calculations. > I honestly can't speak to RAID 5. I don't (and won't) use it. RAID 5 is > a little brutal when under > heavy write load. I use either 1, or 10. Yes, for RAID5 software RAID is better than HW RAID today - the modern gen

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Michael Stone
On Sun, Sep 25, 2005 at 01:41:06PM -0400, Greg Stark wrote: Also, Raid 5 is particularly inappropriate for write-heavy Database traffic. Raid 5 actually hurts write latency dramatically and Databases are very sensitive to latency. Software raid 5 actually may have an advantage here. The main ca

Re: [PERFORM] tsearch2 seem very slow

2005-09-25 Thread Ahmad Fajar
Hi Oleg, Sorry for my late. From the stat() function I got 1,5 million rows, although I've added garbage words to the stop word file, there seem still have garbage words. So I ask for my team to identify the garbage words and add to stop words and I will update the articles after that. And about m

Re: [PERFORM] [HACKERS] Releasing memory during External sorting?

2005-09-25 Thread Simon Riggs
On Fri, 2005-09-23 at 11:31 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > Since we know the predicted size of the sort set prior to starting the > > sort node, could we not use that information to allocate memory > > appropriately? i.e. if sort size is predicted to be more th

Re: [PERFORM] Releasing memory during External sorting?

2005-09-25 Thread Simon Riggs
On Fri, 2005-09-23 at 12:48 -0400, Ron Peacetree wrote: > > I have some indications from private tests that very high memory settings > >may actually hinder performance of the sorts, though I cannot explain that > >and wonder whether it is the performance tests themselves that have issues. > > > H

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Greg Stark
PFC <[EMAIL PROTECTED]> writes: > Which makes me think that I will use Software Raid 5 and convert the > price of the card into RAM. > This should be nice for a budget server. > Gonna investigate now if Linux software RAID5 is rugged enough. Can > always buy the a card later if n

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread PFC
There is a huge advantage to software raid on all kinds of levels. If you have the CPU then I suggest it. However you will never get the performance out of software raid on the high level (think 1 gig of cache) that you would on a software raid setup. It is a bit of a tradeoff but for most

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Joshua D. Drake
Even for RAID5 ? it uses a bit more CPU for the parity calculations. I honestly can't speak to RAID 5. I don't (and won't) use it. RAID 5 is a little brutal when under heavy write load. I use either 1, or 10. An advantage of software raid, is that if the RAID card dies, you have t

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread PFC
The common explanation is that CPUs are so fast now that it doesn't make a difference. From my experience software raid works very, very well. However I have never put software raid on anything that is very heavily loaded. Even for RAID5 ? it uses a bit more CPU for the parity ca

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Joshua D. Drake
Dave Cramer wrote: I would think software raid would be quite inappropriate considering postgres when it is working is taking a fair amount of CPU as would software RAID. Does anyone know if this is really the case ? The common explanation is that CPUs are so fast now that it doesn't make

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Michael Stone
On Sun, Sep 25, 2005 at 10:57:56AM -0400, Dave Cramer wrote: I would think software raid would be quite inappropriate considering postgres when it is working is taking a fair amount of CPU as would software RAID. Does anyone know if this is really the case ? It's not. Modern cpu's can handle

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Mike Rylander
On 9/25/05, Dave Cramer <[EMAIL PROTECTED]> wrote: > I would think software raid would be quite inappropriate considering > postgres when it is working is taking a fair amount of CPU as would > software RAID. Does anyone know if this is really the case ? > I attempted to get some extra speed out o

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Dave Cramer
I would think software raid would be quite inappropriate considering postgres when it is working is taking a fair amount of CPU as would software RAID. Does anyone know if this is really the case ? Dave On 25-Sep-05, at 6:17 AM, Michael Ben-Nes wrote: I would consider Software Raid PFC wr

Re: [PERFORM] Advice on RAID card

2005-09-25 Thread Michael Ben-Nes
I would consider Software Raid PFC wrote: Hello fellow Postgresql'ers. I've been stumbled on this RAID card which looks nice. It is a PCI-X SATA Raid card with 6 channels, and does RAID 0,1,5,10,50. It is a HP card with an Adaptec chip on it, and 64 MB cache. HP Part # :