Re: [PERFORM] SSD + RAID

2009-11-14 Thread Lists
Laszlo Nagy wrote: Hello, I'm about to buy SSD drive(s) for a database. For decision making, I used this tech report: http://techreport.com/articles.x/16255/9 http://techreport.com/articles.x/16255/10 Here are my concerns: * I need at least 32GB disk space. So DRAM based SSD is not a

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Ivan Voras
Lists wrote: Laszlo Nagy wrote: Hello, I'm about to buy SSD drive(s) for a database. For decision making, I used this tech report: http://techreport.com/articles.x/16255/9 http://techreport.com/articles.x/16255/10 Here are my concerns: * I need at least 32GB disk space. So DRAM based

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Heikki Linnakangas
Merlin Moncure wrote: 2009/11/13 Heikki Linnakangas heikki.linnakan...@enterprisedb.com: Laszlo Nagy wrote: * I need at least 32GB disk space. So DRAM based SSD is not a real option. I would have to buy 8x4GB memory, costs a fortune. And then it would still not have redundancy.

[PERFORM] FTS performance with the Polish config

2009-11-14 Thread Wojciech Knapik
Hello I just finished implementing a search engine for my site and found ts_headline extremely slow when used with a Polish tsearch configuration, while fast with English. All of it boils down to a simple testcase, but first some background. I tested on 8.3.1 on G5/OSX 10.5.8 and

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Merlin Moncure
On Sat, Nov 14, 2009 at 6:17 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: lots of ram doesn't help you if: *) your database gets written to a lot and you have high performance requirements When all the (hot) data is cached, all writes are sequential writes to the WAL,

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Heikki Linnakangas
Merlin Moncure wrote: On Sat, Nov 14, 2009 at 6:17 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: lots of ram doesn't help you if: *) your database gets written to a lot and you have high performance requirements When all the (hot) data is cached, all writes are sequential

Re: [PERFORM] FTS performance with the Polish config

2009-11-14 Thread Kenneth Marshall
On Sat, Nov 14, 2009 at 12:25:05PM +0100, Wojciech Knapik wrote: Hello I just finished implementing a search engine for my site and found ts_headline extremely slow when used with a Polish tsearch configuration, while fast with English. All of it boils down to a simple testcase, but

Re: [PERFORM] FTS performance with the Polish config

2009-11-14 Thread Tom Lane
Kenneth Marshall k...@rice.edu writes: On Sat, Nov 14, 2009 at 12:25:05PM +0100, Wojciech Knapik wrote: I just finished implementing a search engine for my site and found ts_headline extremely slow when used with a Polish tsearch configuration, while fast with English. The documentation

Re: [PERFORM] FTS performance with the Polish config

2009-11-14 Thread Pavel Stehule
2009/11/14 Tom Lane t...@sss.pgh.pa.us: Kenneth Marshall k...@rice.edu writes: On Sat, Nov 14, 2009 at 12:25:05PM +0100, Wojciech Knapik wrote: I just finished implementing a search engine for my site and found ts_headline extremely slow when used with a Polish tsearch configuration, while

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Laszlo Nagy
Heikki Linnakangas wrote: Laszlo Nagy wrote: * I need at least 32GB disk space. So DRAM based SSD is not a real option. I would have to buy 8x4GB memory, costs a fortune. And then it would still not have redundancy. At 32GB database size, I'd seriously consider just

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Robert Haas
2009/11/14 Laszlo Nagy gand...@shopzeus.com: 32GB is for one table only. This server runs other applications, and you need to leave space for sort memory, shared buffers etc. Buying 128GB memory would solve the problem, maybe... but it is too expensive. And it is not safe. Power out - data

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Merlin Moncure
On Sat, Nov 14, 2009 at 8:47 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Merlin Moncure wrote: On Sat, Nov 14, 2009 at 6:17 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: lots of ram doesn't help you if: *) your database gets written to a lot and you

Re: [PERFORM] Weird index or sort behaviour

2009-11-14 Thread Tom Lane
Matthew Wakeling matt...@flymine.org writes: [ discussion about applying materialize to a mergejoin's inner indexscan ] I have finally gotten round to doing something about this, and applied the attached patch to CVS HEAD. Could you test it on your problem case to see what happens? If it's not

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Laszlo Nagy
Robert Haas wrote: 2009/11/14 Laszlo Nagy gand...@shopzeus.com: 32GB is for one table only. This server runs other applications, and you need to leave space for sort memory, shared buffers etc. Buying 128GB memory would solve the problem, maybe... but it is too expensive. And it is not safe.

Re: [PERFORM] SSD + RAID

2009-11-14 Thread Laszlo Nagy
* I could buy two X25-E drives and have 32GB disk space, and some redundancy. This would cost about $1600, not counting the RAID controller. It is on the edge. This was the solution I went with (4 drives in a raid 10 actually). Not a cheap solution, but the performance is

Re: [PERFORM] FTS performance with the Polish config

2009-11-14 Thread Oleg Bartunov
Yes, as stated original author use polish ispell dictionary. Ispell dictionary is slow to load first time. In real life it should be no problem. Oleg On Sat, 14 Nov 2009, Pavel Stehule wrote: 2009/11/14 Tom Lane t...@sss.pgh.pa.us: Kenneth Marshall k...@rice.edu writes: On Sat, Nov 14,