Re: Qualifying use of separate TABLESPACES (performance/functionality) - Mailing list pgsql-general

From Christophe Pettus
Subject Re: Qualifying use of separate TABLESPACES (performance/functionality)
Date
Msg-id 70BDA5E1-F800-44CB-A1FC-C7597D53ABCD@thebuild.com
Whole thread Raw
In response to Qualifying use of separate TABLESPACES (performance/functionality)  (Imndlf8r@gmx.com)
Responses Re: Qualifying use of separate TABLESPACES (performance/functionality)
List pgsql-general

> On Jul 16, 2024, at 21:45, Imndlf8r@gmx.com wrote:
> Or, does Postgres expect to be able to access any media however it wants
> (i.e., R/w), regardless of the expected access patterns of the data stored
> there?

Well, yes and no.

PostgreSQL will not respond well to having media that is literally read only in the sense that a write operation to it
willfail.  At some point, it will need to (for example) vacuum the tables, and that will means writes.  That being
said,if the only thing in a tablespace are tables (and their indexes) that are written once then never again, you won't
beconstantly getting writes to them.  You may want to do a VACUUM (ANALYZE, FREEZE) on the tables in those tablespaces
oncethe data is loaded. 

PostgreSQL will be generating WAL as you do data-modifying operations, so that should be aimed at storage that very low
writefatigue.  Be very cautious about using a RAM disk for anything, though, unless you are *very* confident the
batterybackup on it is 100% reliable.  PostgreSQL isn't designed to handle recovery from having the WAL just disappear
outfrom under it on a crash. 


pgsql-general by date:

Previous
From: Imndlf8r@gmx.com
Date:
Subject: Qualifying use of separate TABLESPACES (performance/functionality)
Next
From: Imndlf8r@gmx.com
Date:
Subject: Re: Qualifying use of separate TABLESPACES (performance/functionality)