Обсуждение: Slow Query and Big File Size even after emptying

Поиск
Список
Период
Сортировка

Slow Query and Big File Size even after emptying

От
"Ridvan Lakas ng Bayan S. Baluyos"
Дата:
Hi All,

I checked the file size of my database and it's 115GB. I already figured out which tables suck up all the space and I decided to delete all the entries in them. But still after emptying (DELETE FROM <tablename>), the file size still hasn't changed. I already tried to VACUUM the table. Also, even if there are already 0 records within the table that I emptied, when I query to that table it's so slow and then it just gives a 0 results.

Is there anything that I missed out here? Like do I need to do some other cleanups within postgres(eg. cache, etc)?


TIA for your replies. It would be very much appreciated.


Ridvan

--
リヅバン バルヨス
ridvan.baluyos@qualservcentral.com
http://ridvan.baluyos.net
http://www.onxiam.com/people/rbaluyos

Registered Linux User #439466
Registered Ubuntu User #16034
Q: Have you heard of the Object-Oriented way to get wealthy?
A: Inheritance.

Re: Slow Query and Big File Size even after emptying

От
Mark Roberts
Дата:
On Tue, 2008-07-01 at 11:02 +0800, Ridvan Lakas ng Bayan S. Baluyos
wrote:
> Hi All,
>
> I checked the file size of my database and it's 115GB. I already
> figured out which tables suck up all the space and I decided to delete
> all the entries in them. But still after emptying (DELETE FROM
> <tablename>), the file size still hasn't changed. I already tried to
> VACUUM the table. Also, even if there are already 0 records within the
> table that I emptied, when I query to that table it's so slow and then
> it just gives a 0 results.
>
> Is there anything that I missed out here? Like do I need to do some
> other cleanups within postgres(eg. cache, etc)?
>
>
> TIA for your replies. It would be very much appreciated.
>
>
> Ridvan

You might consider using truncate, if you're serious about removing
those rows.  Otherwise, you could consider a vacuum full, and don't
forget to analyze afterwards.

-Mark