From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
---|---|
To: | "Greg Smith" <greg(at)2ndquadrant(dot)com>, "Jon Nelson" <jnelson+pgsql(at)jamponi(dot)net> |
Cc: | "Vitalii Tymchyshyn" <tivv00(at)gmail(dot)com>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, <mladen(dot)gogala(at)vmsinfo(dot)com> |
Subject: | Re: Slow count(*) again... |
Date: | 2010-10-12 15:29:22 |
Message-ID: | 4CB43882020000250003681C@gw.wicourts.gov |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> wrote:
> Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
>> Usually the sequence used to remove all cached data from RAM
>> before a benchmark is:
>
> All cached data (as cached in postgresql - *not* the Linux system
> caches)..., right?
No. The stop and start of PostgreSQL causes empty PostgreSQL
caches. These lines, in between the stop and start, force the Linux
cache to be empty (on recent kernel versions):
sync
echo 3 > /proc/sys/vm/drop_caches
-Kevin
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-10-12 15:37:00 | Re: [JDBC] Support for JDBC setQueryTimeout, et al. |
Previous Message | bricklen | 2010-10-12 15:12:53 | Re: Slow count(*) again... |
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Harris | 2010-10-12 15:39:19 | Re: Slow count(*) again... |
Previous Message | bricklen | 2010-10-12 15:12:53 | Re: Slow count(*) again... |