Horton

RE: Cache relation sizes?

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Kyotaro HORIGUCHI' <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, "thomas.munro@enterprisedb.com" <thomas.munro@enterprisedb.com>, "david.rowley@2ndquadrant.com" <david.rowley@2ndquadrant.com>, "andres@anarazel.de" <andres@anarazel.de>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-02-06T08:29:54Z
Lists: pgsql-hackers 
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyotaro@lab.ntt.co.jp]
> Just one counter in the patch *seems* to give significant gain
> comparing to the complexity, given that lseek is so complex or it
> brings latency, especially on workloads where file is scarcely
> changed. Though I didn't run it on a test bench.

I expect so, too.


> I'm not sure the duration of the 'permanent' there, but it
> disappears when server stops. Anyway it doesn't need to be
> permanent beyond a server restart.

Right, it exists while the server is running.


Regards
Takayuki Tsunakawa

Commits

  1. Optimize DropRelFileNodesAllBuffers() for recovery.

  2. Cache smgrnblocks() results in recovery.

  3. Use pg_pread() and pg_pwrite() for data files and WAL.

  4. Add a check to prevent overwriting valid data if smgrnblocks() gives a