On Fri, Oct 12, 2012 at 10:31 PM, Tom Lane wrote:
> So I think the original assumption that we didn't need to optimize
> pg_dump's object management infrastructure for blobs still holds good.
> If there's anything that is worth fixing here, it's the number of server
> roundtrips being used ...
>
I wrote:
> Sergio Gabriel Rodriguez writes:
>> I never use oprofile, but for a few hours into the process, I could take
>> this report:
>> 1202449 56.5535 sortDumpableObjects
> Hm. I suspect a lot of that has to do with the large objects; and it's
> really overkill to treat them as full-fledge
Sergio Gabriel Rodriguez writes:
> On Thu, Oct 11, 2012 at 7:16 PM, Tom Lane wrote:
>> 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
On Thu, Oct 11, 2012 at 7:16 PM, Tom Lane wrote:
>
> 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
On 10/11/2012 05:46 PM, Sergio Gabriel Rodriguez wrote:
Hi,
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
Sergio Gabriel Rodriguez 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
Hi,
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?
Hp proliant Xeon G5
32
Sergio Gabriel Rodriguez writes:
> On Thu, Sep 20, 2012 at 11:35 AM, Tom Lane wrote:
>> You wouldn't happen to be
>> trying to use a 9.0 or later pg_dump would you? Exactly what 8.4.x
>> release is this, anyway?
> Tom, thanks for replying, yes, we tried it with postgres postgres 9.1 and
> 9.2 a
On Thu, Sep 20, 2012 at 11:35 AM, Tom Lane wrote:
> You wouldn't happen to be
> trying to use a 9.0 or later pg_dump would you? Exactly what 8.4.x
> release is this, anyway?
>
>
>
Tom, thanks for replying, yes, we tried it with postgres postgres 9.1 and
9.2 and the behavior is exactly the same.
Sergio Gabriel Rodriguez writes:
> Our production database, postgres 8.4 has an approximate size of 200 GB,
> most of the data are large objects (174 GB), until a few months ago we used
> pg_dump to perform backups, took about 3-4 hours to perform all the
> process. Some time ago the process becam
Our production database, postgres 8.4 has an approximate size of 200 GB,
most of the data are large objects (174 GB), until a few months ago we used
pg_dump to perform backups, took about 3-4 hours to perform all the
process. Some time ago the process became interminable, take one or two
days to pr
11 matches
Mail list logo
