| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Mike McCann <mccann(at)mbari(dot)org> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Yuri Levinsky <yuril(at)celltick(dot)com>, Julien Cigar <jcigar(at)ulb(dot)ac(dot)be>, Arjen van der Meijden <acmmailing(at)tweakers(dot)net> |
| Subject: | Re: Hardware suggestions for maximum read performance |
| Date: | 2013-05-14 01:09:58 |
| Message-ID: | CAOR=d=03attUhieRnWAXS93kTvyiHGheWBW_07aLKByKAqHx6w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, May 13, 2013 at 5:58 PM, Mike McCann <mccann(at)mbari(dot)org> wrote:
> We assume that steps taken to improve the worst-case query scenario will
> also improve these kind of queries. If anything above pops out as needing
> better planning please let us know that too!
Bad assumption. If your real workload will be queries like the one
here that takes 700 ms, but you'll be running 10,000 of them a second,
you're tuning / hardware choices are going to be much different then
if your query is going to be the previous 7 second one. Use realistic
queries, not ones that are nothing like what your real ones will be.
then use pgbench and its ability to run custom sql scripts to get a
REAL idea how your hardware performs. Note that if you will run the
slow query you posted like once a minute and roll it up or cache it
then don't get too worried about it. Pay attention to the queries that
will add up, in aggregate, to your greatest load.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2013-05-14 04:02:04 | Re: Setting vacuum_freeze_min_age really low |
| Previous Message | Mike McCann | 2013-05-13 23:58:17 | Re: Hardware suggestions for maximum read performance |