| From: | "Ron Mayer" <ron(at)intervideo(dot)com> |
|---|---|
| To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Matthew Nuzum" <cobalt(at)bearfruit(dot)org>, "'Pgsql-Performance'" <pgsql-performance(at)postgresql(dot)org> |
| Cc: | <ron(at)intervideo(dot)com> |
| Subject: | Re: Caching (was Re: choosing the right platform) |
| Date: | 2003-04-11 17:25:24 |
| Message-ID: | POEDIPIPKGJJLDNIEMBECEBDCJAA.ron@intervideo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Josh wrote:
>Ron,
>> Below is an example of another real-world query from the same
>> reporting system that benefits from a sort_mem over 32M.
>> Explain analyze (below) shows a 40% improvement by having
>> the sort fit in memory.
>
>Cool! That's a perfect example of sizing sort_mem for the query. Mind if I
>steal it for an article at some point?
Gladly!
BTW... if you're writing a tuning article, the most interesting one
I've seen is:
http://otn.oracle.com/oramag/webcolumns/2002/techarticles/scalzo_linux01.html
I like how they broke down the process in many steps and measured after each.
I'm was intrigued by how much Linux's VM tweaking (vm.bdflush) affected
performance mattered as much at the more-commontly tweaked "noatime".
Ron
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shane hill | 2003-04-12 17:14:52 | update query blows out |
| Previous Message | Josh Berkus | 2003-04-11 16:15:15 | Re: Caching (was Re: choosing the right platform) |