From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sergio Gabriel Rodriguez <sgrodriguez@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: problems with large objects dump
Date: Thu, 11 Oct 2012 18:16:33 -0400
Message-ID: <1269.1349993793@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMHBdEqPt+g+aAUVfE4zV01UOLPsBuU2kpJ2jJHWs2Lr_8x1yg@mail.gmail.com>
References: <CAMHBdEoS3b7XZ2JWWG+Y71MGpnDJFLM3U0WnFMxvhOe=Oq2q_w@mail.gmail.com>
<16863.1348151708@sss.pgh.pa.us>
<CAMHBdEroekZuQZdqXyX5m=_Z6L-+-k_jWvnEi5JbkS_iy_LQ+w@mail.gmail.com>
<CAMHBdEqPt+g+aAUVfE4zV01UOLPsBuU2kpJ2jJHWs2Lr_8x1yg@mail.gmail.com>
Sergio Gabriel Rodriguez <sgrodriguez@gmail.com> writes:
> I tried with Postgresql 9.2 and the process used to take almost a day
> and a half, was significantly reduced to 6 hours, before failing even used
> to take four hours. My question now is, how long should it take the backup
> for a 200GB database with 80% of large objects?
It's pretty hard to say without knowing a lot more info about your system
than you provided. One thing that would shed some light is if you spent
some time finding out where the time is going --- is the system
constantly I/O busy, or is it CPU-bound, and if so in which process,
pg_dump or the connected backend?
Also, how many large objects is that? (If you don't know already,
"select count(*) from pg_largeobject_metadata" would tell you.)
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, sgrodriguez@gmail.com
Subject: Re: problems with large objects dump
In-Reply-To: <1269.1349993793@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox