Re: C partition management

From: mkohls <mkohls(at)trinity-health(dot)org>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: C partition management
Date: 2014-09-03 12:44:41
Message-ID: 1803B059154D6A45BF24B247ACF346C550FB812D@NODCMSTMBX01.no.trinity-health.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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+s1045698n5817464h14(at)n5(dot)nabble(dot)com]
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<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5817454&code=bWtvaGxzQHRyaW5pdHktaGVhbHRoLm9yZ3w1ODE3NDU0fC0xMTIwMzE5ODY2>.
NAML<http://postgresql.1045698.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>

--
View this message in context: http://postgresql.1045698.n5.nabble.com/C-partition-management-tp5817454p5817536.html
Sent from the PostgreSQL - novice mailing list archive at Nabble.com.

In response to

Browse pgsql-novice by date

  From Date Subject
Next Message Stuart Nadin 2014-09-03 15:15:27 Unable to bootstrap standby server
Previous Message David G Johnston 2014-09-02 21:27:44 Re: C partition management