From: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_restore takes ages |
Date: | 2003-10-03 14:28:12 |
Message-ID: | 3F7D877C.4020006@persistent.co.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Vivek Khera wrote:
> SD> footprint. I dropped the table and recreated it. Also created index
> SD> before loading data. The loading was slow with this approach but it
> SD> finished in 3 hours. And I had an updated index as well. Just had to
> SD> run vacuum over it.
>
> I cannot believe that this was faster than load data followed by
> create index. Perhaps you needed to bump sort_mem so the index could
> be created more efficiently. I also find that bumping up
> checkpoint_segments to a high number speeds things up considerably.
Well, In my case speed wasn't the issue. I put $PGDATA on a 12/13GB partition
and loaded 3GB of table. When I went to create index, it ran out of rest of the
free space which was close to 9GB. Actually I killed it because when it started
it had 9GB free and when I killed it, there was only 150MB free left.
Oracle had same problems. With tablespaces set to auto extent it ate huge amount
of space.
I posted this earlier and Tom remarked it the same, saying that it should be
same one way or other.
Anyway the project abandoned all the database and went to in memory structures..:-)
Shridhar
From | Date | Subject | |
---|---|---|---|
Next Message | Stef | 2003-10-03 14:30:40 | Postgres low end processing. |
Previous Message | Bruno Wolff III | 2003-10-03 14:22:09 | Re: book on advanced postgresql? |