Re: DB on mSATA SSD - Mailing list pgsql-general

From John McKown
Subject Re: DB on mSATA SSD
Date
Msg-id CAAJSdjju90+vV+OdVW7nonknF49EBUYBYcjvxcQKv=LPQtT4nA@mail.gmail.com
Whole thread Raw
In response to DB on mSATA SSD  (Job <Job@colliniconsulting.it>)
Responses Re: DB on mSATA SSD
List pgsql-general
On Thu, Apr 23, 2015 at 6:07 AM, Job <Job@colliniconsulting.it> wrote:
Dear Postgresql mailing list,

we use Postgresql 8.4.x on our Linux firewall distribution.
Actually, we are moving from standard SATA disk to mSATA SSD solid drive, and we noticed that the DB, using lots of indexes, is writing a lot.

In some monthes, two test machine got SSD broken, and we are studying how to reduce write  impact for DB.

Are there some suggestions with SSD drives?
Putting the DB into RAM and backing up periodically to disk is a valid solutions?

Or, is storing indexes on a ram drive possible?

Thank you in advance for your appreciated interest!

Best regards,
Francesco

​That's a really old release. But I finally found some doc on it. And 8.4 does appear to have TABLESPACEs in it. 


<quote>

To define a tablespace, use the CREATE TABLESPACE command, for example::

CREATE TABLESPACE fastspace LOCATION '/mnt/sda1/postgresql/data';

The location must be an existing, empty directory that is owned by the PostgreSQL system user. All objects subsequently created within the tablespace will be stored in files underneath this directory.

</quote>

By using tablespaces appropriately, you can direct individual tables onto different media. I do not know what is causing your "excessive" writing, but if it is temporary tables, they you can set a TABLESPACE aside for those tables which is somewhere other than your SSD (actual hard drive, or RAM disk if you have enough memory to create a RAM disk). 


<quote>
temp_tablespaces (string)

This variable specifies tablespace(s) in which to create temporary objects (temp tables and indexes on temp tables) when a CREATE command does not explicitly specify a tablespace. Temporary files for purposes such as sorting large data sets are also created in these tablespace(s).

The value is a list of names of tablespaces. When there is more than one name in the list, PostgreSQL chooses a random member of the list each time a temporary object is to be created; except that within a transaction, successively created temporary objects are placed in successive tablespaces from the list. If the selected element of the list is an empty string, PostgreSQL will automatically use the default tablespace of the current database instead.

When temp_tablespaces is set interactively, specifying a nonexistent tablespace is an error, as is specifying a tablespace for which the user does not have CREATE privilege. However, when using a previously set value, nonexistent tablespaces are ignored, as are tablespaces for which the user lacks CREATE privilege. In particular, this rule applies when using a value set in postgresql.conf.

The default value is an empty string, which results in all temporary objects being created in the default tablespace of the current database.

</quote>

​I agree that is sounds like you're not using quality SSD drives.​


--
If you sent twitter messages while exploring, are you on a textpedition?

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

pgsql-general by date:

Previous
From: Vick Khera
Date:
Subject: Re: DB on mSATA SSD
Next
From: Chris Mair
Date:
Subject: Re: DB on mSATA SSD