pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Claudio Freire <klaussfreire@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tomas Vondra <tv@fuzzy.cz>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Performance
Date: Tue, 26 Apr 2011 09:49:39 +0200
Message-ID: <BANLkTikfAzvviWVmp-e81Ei2gNV4aaECQg@mail.gmail.com> (raw)
In-Reply-To: <D2F0DB51-7D42-4573-99CA-B72E28440B16@gmail.com>
References: <DF2D5436-117C-4D02-9B3C-A55723B7DDE1@darkstatic.com>
	<20110412171855.GA14292@tux>
	<FC3A3A2B-3ECB-41BA-8F94-356D6FED3695@darkstatic.com>
	<4DA496FA.3070908@fuzzy.cz>
	<8F22D592-23C1-4A3C-94A5-48363332ADD3@darkstatic.com>
	<4DA4BFA2.5060601@fuzzy.cz>
	<B93DFBBB-DA56-4044-A508-0B7E4A2CFD28@darkstatic.com>
	<4DA4D40A.4010200@fuzzy.cz>
	<A0B9339E-9D58-4842-A206-050B773360B6@darkstatic.com>
	<4DA56DA8020000250003C783@gw.wicourts.gov>
	<BANLkTinJqXqErAtQg--1MOaw2LJNFZmwOg@mail.gmail.com>
	<BANLkTimyWkoX8Dj=4CKAjhY82ibru-An7g@mail.gmail.com>
	<4DA6216E.9020907@fuzzy.cz>
	<BANLkTim_m-oz3UMXEKUdFjWJ6uuAza79cw@mail.gmail.com>
	<4DA63125.5070106@fuzzy.cz>
	<BANLkTikYtnzTfS8Yjc-3ap9kysXLLpJwmg@mail.gmail.com>
	<D2F0DB51-7D42-4573-99CA-B72E28440B16@gmail.com>

On Tue, Apr 26, 2011 at 7:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Apr 14, 2011, at 2:49 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> This particular factor is not about an abstract and opaque "Workload"
>> the server can't know about. It's about cache hit rate, and the server
>> can indeed measure that.
>
> The server can and does measure hit rates for the PG buffer pool, but to my knowledge there is no clear-cut way for PG to know whether read() is satisfied from the OS cache or a drive cache or the platter.

Isn't latency an indicator?

If you plot latencies, you should see three markedly obvious clusters:
OS cache (microseconds), Drive cache (slightly slower), platter
(tail).

I think I had seen a study of sorts somewhere[0]...

Ok, that link is about sequential/random access, but I distinctively
remember one about caches and CAV...

[0] http://blogs.sun.com/brendan/entry/heat_map_analytics



view thread (60+ messages)  latest in thread

Message-ID: <BANLkTikfAzvviWVmp-e81Ei2gNV4aaECQg@mail.gmail.com>
Permalink:  ../BANLkTikfAzvviWVmp-e81Ei2gNV4aaECQg@mail.gmail.com/
Also on:    postgresql.org/message-id/BANLkTikfAzvviWVmp-e81Ei2gNV4aaECQg@mail.gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: klaussfreire@gmail.com, robertmhaas@gmail.com, tv@fuzzy.cz
  Subject: Re: Performance
  In-Reply-To: <BANLkTikfAzvviWVmp-e81Ei2gNV4aaECQg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox