Re: database file size bloat - Mailing list pgsql-general

From Brian Neal
Subject Re: database file size bloat
Date
Msg-id 200004141919.PAA23645@mailhost.bellsouth.net
Whole thread Raw
In response to database file size bloat  (Matthew Arnison <maffew@physics.usyd.edu.au>)
List 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 by date:

Previous
From: Ed Loehr
Date:
Subject: Re: PostgreSQL (fwd)
Next
From: Ed Loehr
Date:
Subject: Re: Does error within transaction imply restarting it?