Re: database file size bloat
От | Brian Neal |
---|---|
Тема | Re: database file size bloat |
Дата | |
Msg-id | 200004141919.PAA23645@mailhost.bellsouth.net обсуждение исходный текст |
Ответ на | database file size bloat (Matthew Arnison <maffew@physics.usyd.edu.au>) |
Список | pgsql-general |
>Few commments ... the 'row size limit' should be gone in v7.1, as Jan is >working on implementing TOAST for that ... Cool. How does this solution stand up in terms of performance? Will searches through TEXT/BLOB fields be acceptably fast? >AS for the process pool ... there are two camps here ... if you use >threads, when one threads crashes the server, the server is done. With >forking,if one backend dies, the server is still running ... in a 24x7 >shop, I'd rather the solution that doesn't die cause JoeBlow down the hall >blew out something with his query :) I have to disagree with you here, but I suppose it depends upon your application. In the places I've worked and for the stuff I'm doing now, you would never run queries that would crash the server on a production machine...so the Joe Blow example would not happen (generally). Beyond that, I think the process pool has some terrible downsides...mostly resource usage and performance in terms of forking, etc. The amount of shared memory required to handle a large number of back-end processes, for example, is pretty intense, at least from my experience. I had to increase the system's shm hard limit to get it to work with the number of backends I needed (slightly less, actually, I would have preferred more)....to do this I had to reboot. Because of the nature of our production server, I cannot reboot it, and so I cannot ever run pgsql if this doesn't go away (I'm not prodding you to do anything about it on my account, though). Apache is another program using process pools, and it can use a startling amount of resources during load spikes...it's sometimes frightening to see how quickly memory can evaporate when it begins forking large amounts of processes to deal with spikes. Apache 2.0 is moving to a threaded solution, as far as I know. Also, most other major webservers and databases use threaded-implementations as well. I don't think the stability/reliability of a single multi-threaded process is a major issue as long as the program is well written and the site running the installation is properly maintained. Also, you can use a watchdog to restart it in the event that it does die. -Brian
В списке pgsql-general по дате отправления: