Re: bloating index, pg_restore

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: salah jubeh <s_jubeh(at)yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
Cc: pgsql <pgsql-general(at)postgresql(dot)org>
Subject: Re: bloating index, pg_restore
Date: 2013-03-28 15:17:54
Message-ID: 1364483874.57254.YahooMailNeo@web162902.mail.bf1.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

salah jubeh <s_jubeh(at)yahoo(dot)com> wrote:

> Well my question was not very precise, the postgresql version is
> 8.3 which is not supported, so I wanted to migrate to a newer
> version which is 9.1.
>
> I have used pg_dump with -Fc option and I was monitoring the
> pg_restore activity.  Normally, the dump and restore takes from
> 30-40 minutes; but yesterday when the indexes are bloated  - I do
> not know how this could happen in one or two days, the database
> size increased from 700 MiB to 13 GiB -  the pg_restore on 9.1
> takes around 6 hours.  Since pg_restore is using insert into
> (....). How can bloated indexes affect the restore performance.
>
> I have re-indexed one table  and the size dropped to again 700
> MiB. So what could be the problem here?

You are still leaving way to much to the imagination here.

What version of pg_dump are you using for the dump?

Why are there enough dumps to have a "normallY' timing?

What is this "one or two day" gap you're talking about?  What
happened during that time?

Are you doing multiple tests with a new database to restore to each
time, dumping and restoring multiple databases within one cluster,
or what?

Without more detail, we can only guess.

--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-general by date

  From Date Subject
Next Message CR Lender 2013-03-28 19:19:49 Re: pg_stat_get_last_vacuum_time(): why non-FULL?
Previous Message Tom Lane 2013-03-28 14:36:28 Re: Money casting too liberal?