Search Postgresql Archives

to drop a 30GB database. is it slow?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi,

we have a database, which was not vacuumed for a looooong time.

right now it's size is 30GB. it only contains a simple table with 90rows.

it seems that it's so big because it was not vacuumed for a long time.

is this a reasonable assumption?

now we'd like to somehow 'compact' him.

it seems that a normal vacuum process does not recover the disk space.

there seems to be a "full" vacuum process, which can also recover the 'lost' space, but it blocks the whole postgresql db, so other processes cannot read/write to it.

is this correct?

so, we're thinking about dropping the whole db, and recreate it (because it only stores session data, so if they're lost, it's not THAT bad),
because this will be much faster.

am i correct to assume that if we drop it, postgresql recovers that 30GB of disk space?

and, how long this step (the db-drop) usually take? is it's "speed" comparable to a normal file-delete operation?

i'm only afraid that maybe if we issue the drop-db command, it will take for example 30minutes...

thanks,
gabor

p.s: and all those questions like 'why didnt you vacuum it before' ... it wasn't us. we took over this project just recently.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux