Re: [PERFORM] fsync vs open_sync
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 systems, I do know that it is the default when installing, so I'd suggest you might check into it. -- Until later, Geoffrey Registered Linux User #108567 ATT Certified UNIX System Programmer - 1995 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PERFORM] Dump/Restore performance improvement
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 in memory(if possible) and add's a SET work_maintenance_mem=the value calculated (IF this value is less than work_maintanence_max_mem. ) This seems fairly pointless to me. How is this different from just setting maintenance_work_mem as large as you can stand before importing the dump? Making any decisions at dump time seems wrong to me in the first place; pg_dump should not be expected to know what conditions the restore will be run under. I'm not sure that's what you're proposing, but I don't see what the point is in practice. It's already the case that maintenance_work_mem is treated as the maximum memory you can use, rather than what you will use even if you don't need it all. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] fsync vs open_sync
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 with Windows is that I think it could be made much faster, without too much effort (mainly some tweaking in the Disk IO field), but Microsoft doesn't do it. Why ? I can't understand this. in Linux. You can write 1 files in one second and the HDD is still idle... then when it decides to flush it all goes to disk in one burst. You can not trust your data in this. That's why I mentioned that it did not relate to database type performance. If the computer crashes while writing these files, some may be partially written, some not at all, some okay... the only certainty is about filesystem integrity. But it's exactly the same on all Journaling filesystems (including NTFS). Thus, with equal reliability, the faster wins. Maybe, with Reiser4, we will see real filesystem transactions and maybe this will translate in higher postgres performance... I've had my computers shutdown violently by power failures and no reiserfs problems so far. NTFS is very crash proof too. My windows machine bluescreens twice a day and still no data loss ;) If you have the BSOD twice a day then you have a broken driver or broken HW. CPU overclocked ? I think this machine has crap hardware. In fact this example was to emphasize the reliability of NTFS : it is indeed remarkable that no data loss occurs even on such a crap machine. I know Windows has got quite reliable now. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] Table UPDATE is too slow
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 libraries can deal with tables being renamed while in use, perhaps someone can shed some light on this. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PERFORM] Tanking a server with shared memory
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 amount of SYSV semaphores. The other has a normal amount, when testing under the former database server things load up fine, clients can connect and all information is as it should. When I test under the normal setup the machine tanks.No core dumps, no errors produced, just a near instant lock-up of the server itself and that is with a non-privileged user. 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? Martin Foster Creator/Designer Ethereal Realms [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
