Re: [PERFORM] fsync vs open_sync

2004-09-05 Thread Geoffrey
Christopher Browne wrote: I'm not sure what all SuSE supports; they're about the only other Linx vendor that EMC would support, and I don't expect that Reiser4 yet fits into the "supportable" category :-(. I use quite a bit of SuSE, and although I don't know their official position on Reiser file

Re: [PERFORM] Dump/Restore performance improvement

2004-09-05 Thread Tom Lane
Adi Alurkar <[EMAIL PROTECTED]> writes: > 1) Add a new config paramter e.g work_maintanence_max_mem this will > the max memory postgresql *can* claim if need be. > 2) During the dump phase of the DB postgresql estimates the > "work_maintenance_mem" that would be required to create the index

Re: [PERFORM] fsync vs open_sync

2004-09-05 Thread Pierre-Frédéric Caillaud
Were you upset by my message ? I'll try to clarify. I understood from your email that you are a Windows haters Well, no, not really. I use Windows everyday and it has its strengths. I still don't think the average (non-geek) person can really use Linux as a Desktop OS. The problem I have w

Re: [PERFORM] fsync vs open_sync

2004-09-05 Thread Pierre-Frédéric Caillaud
I trust ReiserFS 3. I wouldn't trust the 4 before maybe 1-2 years. On Sun, 05 Sep 2004 07:41:29 -0400, Geoffrey <[EMAIL PROTECTED]> wrote: Christopher Browne wrote: I'm not sure what all SuSE supports; they're about the only other Linx vendor that EMC would support, and I don't expect t

Re: [PERFORM] Table UPDATE is too slow

2004-09-05 Thread Marinos J. Yannikos
Ron St-Pierre wrote: We have a web based application with data that is updated daily. The biggest bottleneck occurs when we try to update one of the tables. This table contains 58,000 rows and 62 columns, and EVERY column is indexed. Have you thought of / tried using 2 separate databases or table

Re: [PERFORM] Table UPDATE is too slow

2004-09-05 Thread Kevin Barnard
Do all of the commands to swap tables in a transaction.  The table gets locked briefly but should have a lot less impact then the update command. On Mon, 06 Sep 2004 01:28:04 +0200, Marinos J. Yannikos <[EMAIL PROTECTED]> wrote: > > That said, I'm not entirely sure how well postgres' client libr

[PERFORM] Tanking a server with shared memory

2004-09-05 Thread Martin Foster
I have been experimenting with the 'IPC::Shareable' module under the native implementation of Perl 5 for OpenBSD 3.5. While it is not loaded by default it is a pure pure implementation. I have tested this module under two machines, one which used to run PostgreSQL and has a higher then normal

Re: [PERFORM] Tanking a server with shared memory

2004-09-05 Thread Tom Lane
Martin Foster <[EMAIL PROTECTED]> writes: > While I know this is a Perl issue, but figured I might be able to gain > some insight on how a server could drop without at least generating a > panic. Any ideas? The standard spelling for this is "kernel bug". Send a reproducible example to the Open