| 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: | 871vfivsfa.fsf@hi-media-techno.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
http://tsung.erlang-projects.org/
Regards,
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matthew Wakeling | 2010-03-18 12:15:01 | Re: pg_dump far too slow |
| Previous Message | Eger, Patrick | 2010-03-18 01:01:16 | Re: Forcing index scan on query produces 16x faster |