Re: C partition management - Mailing list pgsql-novice

From mkohls
Subject Re: C partition management
Date
Msg-id 1803B059154D6A45BF24B247ACF346C550FB812D@NODCMSTMBX01.no.trinity-health.org
Whole thread Raw
In response to Re: C partition management  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-novice

Thanks David,

Mirth is an interface engine.   It is processing HL7 messages and writing them to a separate SQL database.  Progresql was recommended by Mirth as the database to house the Mirth interface settings.

Sounds like I need to post my question to the Mirth forum, instead of Progresql.

 

 

From: David G Johnston [via PostgreSQL] [mailto:ml-node+[hidden email]]
Sent: Tuesday, September 02, 2014 5:28 PM
To: Michael Kohls
Subject: Re: C partition management

 

mkohls wrote

I am brand new to Progresql.  I have installed it along with an upgrade to Mirth application, to replace SQL.
I have installed version 9.3 to the c drive partition.  Mirth has been running well with Progresql for 1 month.  Today in evaluating Progresql, I noticed it is using a lot of the c drive partition and growing.  Mainly C:\Program Files\PostgreSQL\9.3\data\base\16393 which has grown to 23 GB.  It contains no folders, just files, and some are appended with .1, .2, .3, .4, .5, with .6 being the maximum.  It also contains some _fsm and _vm files.  I have read online about vacuum, but it is not clear to me if this will help with my issue.  What is the best way to manage this file so I do not use up all my resource?

Those are your data files and indexes - broken upon into 1GB chunks - with some additional meta-data files.

I assume you are actually storing data into this database - in which case the size of the database will grow as you continue do that.

Without a description of what this "Mirth" is - or more generally an idea of how the database is being used - it will be impossible to diagnose whether this is normal or abnormal behavior and suggest options to reduce the amount of data stored.

If you get really out-of-whack VACUUM FULL can reclaim free-space from the system - the normal VACUUM will typically not be useful for this task.  Other options exist but until you know cause doing anything is likely to be wasted effort.

David J.


If you reply to this email, your message will be added to the discussion below:

http://postgresql.1045698.n5.nabble.com/C-partition-management-tp5817454p5817464.html

To unsubscribe from C partition management, click here.
NAML



View this message in context: RE: C partition management
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.

pgsql-novice by date:

Previous
From: mkohls
Date:
Subject: C partition management
Next
From: Stuart Nadin
Date:
Subject: Unable to bootstrap standby server