Comment:
On Tue, Sep 9, 2008 at 2:07 PM, Andrew Sullivan <noway@spam.com> wrote:
>
> . . . your figuring here is indeed simplistic. Every day I see
> requests for help from people who have followed the rule of thumb "1/4
> of memory for shared_buffers", except that they're also running
> apache+jakarta, MySQL, and a mail server on the same box. They wonder
> why the stock advice is so wrong. It's wrong because a
> general-purpose tool is almost never going to come pre-set for every
> possible workload you might want to throw at it. So even "how much
> memory" there is on the machine is a question that is harder to answer
> than it might seem. Disk layout, data access patterns, even the
> filesystem you choose can make significant differences in how the
> system performs.
Just as common is the beginner showing up with an 8 core opteron
server with 64 Gigs of ram trying to get fast write transactions on a
single 7200 rpm 500G sata drive.
> Finally, part of the reason people make these claims is because they
> tend to hold Postgres up against toy systems that are _not_ designed
> to scale up. A certain well known database product, for instance, has
> been struggling for the last several years to turn itself into a
> full-featured, high-volume, safe transactional system. But the seams
> keep showing, because it just wasn't designed for this workload in the
> first place. But it sure is fast out of the box on a single-user
> system!
reference tweakers.net
http://tweakers.net/reviews/649/8/database-test-sun-ultrasparc-t1-vs-punt-amd-opteron-pagina-8.html
http://tweakers.net/reviews/661/6/database-test-intel-xeon-clovertown-x5355-pagina-6.html
--
Sent via pgsql-general mailing list (pgsql-noway@spam.com)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Questions or comments? Feel free to post them here. No login or id required.
