Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers advice

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pierre C <lists(at)peufeu(dot)com>, Dave Crooke <dcrooke(at)gmail(dot)com>, Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers advice
Date: 2010-03-18 10:24:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Greg Smith <greg(at)2ndquadrant(dot)com> writes:
>  I'm not sure how to make progress on similar ideas about
> tuning closer to the filesystem level without having something automated
> that takes over the actual benchmark running and data recording steps; it's
> just way too time consuming to do those right now with every tool that's
> available for PostgreSQL so far.  That's the problem I work on, there are
> easily a half dozen good ideas for improvements here floating around where
> coding time is dwarfed by required performance validation time.

I still think the best tool around currently for this kind of testing is
tsung, but I've yet to have the time to put money where my mouth is, as
they say. Still, I'd be happy to take some time a help you decide if
it's the tool you want to base your performance testing suite on or not.


In response to


pgsql-performance by date

Next:From: Matthew WakelingDate: 2010-03-18 12:15:01
Subject: Re: pg_dump far too slow
Previous:From: Eger, PatrickDate: 2010-03-18 01:01:16
Subject: Re: Forcing index scan on query produces 16x faster

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group