to drop a 30GB database. is it slow?

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.