Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dpVTa-0005ze-8e for pgsql-performance@arkaria.postgresql.org; Wed, 06 Sep 2017 08:14:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dpVTZ-0001by-Ey for pgsql-performance@arkaria.postgresql.org; Wed, 06 Sep 2017 08:14:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dpVRo-0006ti-9Z for pgsql-performance@postgresql.org; Wed, 06 Sep 2017 08:12:32 +0000 Received: from mail-io0-x22e.google.com ([2607:f8b0:4001:c06::22e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dpVRk-0001wU-GW for pgsql-performance@postgresql.org; Wed, 06 Sep 2017 08:12:31 +0000 Received: by mail-io0-x22e.google.com with SMTP id z67so22294311iof.3 for ; Wed, 06 Sep 2017 01:12:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=HmX97xbW+3vnWuO0DNy3xyRguBrQiQMzIJY0zwWtVoc=; b=Zns3IM94ewxiJPaA3ILVCyETOqJry7doi9d8AEk9U7jRjwmD9aNnC6WqBtCXbjVGBO ozqXGhRHQpZeG7nbHv59+4Grw3K2Gng9U8EXZfygnQhJaWmJXFvjMirtOCPVX+AYPhuG xOO+AP51EojDfy5r9JwEPpiX6aOZSXPAwVsTTEl/dh2zlapjrKC7iV421h1NojzLwqhI TbyF/PgSrJQFwWIsVCwSh+b7WTuVUckHrx/roA+eQSQPOB3yiUPsCIzvzZQIb9j65EtO ApgyVeJDB3QC2wBlEIMMrpYcx+7ZVsuAWpNUyU1GeyJI8DErc7bAHfoufeAemNwqfmxj NccA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HmX97xbW+3vnWuO0DNy3xyRguBrQiQMzIJY0zwWtVoc=; b=BKOJ9pIenHqxGd/aijS6wTFXTgz8htT7+2EU0Caqnw/FEUBDYpYR0b0jtYDWD9NUab qgqHVlX8wBfkMQdrsul+6C4rBlk3Yd+sC2URGyLWLzD4TTLVmVZt/+pAPvhVnIu7XGCU nYX7A33UL3D8PiT4aT4oGeKkqrR8r4/cm+sAOS1xRAnMu0AK2E/bIlGMhKtWLjZ5Hl8T KIhyEkdL7hmo3dipQmjOpdBj3vFt1VI1516Llekwu5G5Qf8M8AOmT8ki1l+muySC4+8H mZOAM9JcTvwW3KZTqRmfjrXG7D8nHunOvbwoCOeab1lt8GhjaylBEdmnTZO9BRy3yHhu 9tAw== X-Gm-Message-State: AHPjjUgpq9U3mNCMAyRyp4OCc1VSNrjXctyHENaX4EaUro9KoI/2BmEH UAZ+mboAgkUZjWUj8ekpA1ibfrqAEz8r X-Google-Smtp-Source: AOwi7QDrFbAZJIts0FP8dDKBZmCENgnBRyI0KsivBQP7g9WDUhQc78mOCh8l7BlkSRpRdZYSwCWwpYxjFT7QGj/FLO8= X-Received: by 10.107.158.21 with SMTP id h21mr849044ioe.256.1504685546614; Wed, 06 Sep 2017 01:12:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.140.148 with HTTP; Wed, 6 Sep 2017 01:12:26 -0700 (PDT) From: Soni M Date: Wed, 6 Sep 2017 15:12:26 +0700 Message-ID: Subject: OS cache management To: "pgsql-performance@postgresql.org" Content-Type: multipart/alternative; boundary="001a11402f288134b7055880e7b5" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --001a11402f288134b7055880e7b5 Content-Type: text/plain; charset="UTF-8" Hello All, I would like to know about how OS cache works for postgres table and index file. Let's say I have 10 year data, and commonly used data only the last 1 year. This data is quite big, so each table and index file is divided into several file in PGDATA/base Let's say 1 index named order_by_date has relfilenode = 1870772348, and it's file consist of 1870772348, 1870772348.1, and 1870772348.2 And for oftenly queried 1 year data, do ALL files for the order_by_date pushed to OS cache ? or it's just 1 file that contains index to this 1 year data. How about index named order_by_customer, will ALL the index files pushed to OS cache ? Can someone please explain about how OS cache works for this condition. Thanks very much for the explanation. -- Regards, Soni Maula Harriz --001a11402f288134b7055880e7b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All, I would like to know about how OS cache works f= or postgres table and index file.

Let's say I have 1= 0 year data, and commonly used data only the last 1 year. This data is quit= e big, so each table and index file is divided into several file in PGDATA/= base

Let's say 1 index named order_by_date has= relfilenode =3D=C2=A01870772348, and it's file consist of=C2=A01870772= 348, 1870772348.1, and 1870772348.2

And for oftenl= y queried 1 year data, do ALL files for the order_by_date pushed to OS cach= e ? or it's just 1 file that contains index to this 1 year data.
<= div>
How about index named order_by_customer, will ALL the in= dex files pushed to OS cache ?

Can someone please = explain about how OS cache works for this condition.

Thanks very much for the explanation.

--
Regards,

<= /div>Soni Maula Harriz
--001a11402f288134b7055880e7b5--