Re: Slow count(*) again...

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

In response to

Browse pgsql-hackers by date

  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...

Browse pgsql-performance by date

  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...