Re: PostGreSQL 8.1.0 : out of memory during vacuum full - Mailing list pgsql-general

From DANTE ALEXANDRA
Subject Re: PostGreSQL 8.1.0 : out of memory during vacuum full
Date
Msg-id 439EEF43.5020905@BULL.NET
Whole thread Raw
In response to PostGreSQL 8.1.0 : out of memory during vacuum full analyze  (DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET>)
List pgsql-general
Thank you for your answer.
Instead of  launching a VACUUM FULL ANALYZE on the "big" table, I will
try to use the "ALTER TABLE SET STATISTICS" command.

I will done this in a second time, during the optimization of  the
benchmark.

Best regards,
Alexandra DANTE


Tom Lane a écrit :

>DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET> writes:
>
>
>>Is it correct ? Why ANALYZE has taken less than one minute ?
>>
>>
>
>That's what it's supposed to do --- ANALYZE just samples the table,
>so it's fast even on very large tables.
>
>If you think you need better statistics, you could increase the
>statistics target for ANALYZE (see ALTER TABLE SET STATISTICS),
>but VACUUM FULL per se is not going to improve them at all.
>VACUUM and ANALYZE have entirely different purposes --- it's only
>historical happenstance that there is a combination command to do
>both.
>
>            regards, tom lane
>
>
>

DANTE ALEXANDRA a écrit :

> Thank you for your answer.
> To give you more explanations, first, I have launched the ANALYZE
> command on this big table, but the elasped time was very short. As my
> queries launched on this table were very slow, I have tried to launch
> the VACUUM FULL ANALYZE to update the statistics.
>
> Is it correct ? Why ANALYZE has taken less than one minute ?
>
> Thanks for your help.
>
> Regards
> Alexandra DANTE
>
>
> Tom Lane a écrit :
>
>> DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET> writes:
>>
>>
>>> Then, on each table, I have launched the "VACUUM FULL ANALYZE"
>>> command as a non-root user.
>>> This command failed on the last table, the biggest, called
>>> "lineitem" which contains 1799989091 rows (near 300 Gb of datas).
>>>
>>
>>
>> VACUUM FULL requires workspace proportional to the number of blocks in
>> the table.  You probably need to bump up the kernel's per-process memory
>> limit (see ulimit and so on) if you want to VACUUM FULL such a large
>> table.
>>
>> My advice: you shouldn't be using VACUUM FULL anyway.  Quite aside from
>> the memory issue, it's likely to take forever and a day.
>>
>>             regards, tom lane
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 5: don't forget to increase your free space map settings
>>
>>
>>
>


pgsql-general by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Bug#342369: PostgreSQL 8.1.0 RHEL / Debian incompatible
Next
From: Stephen Frost
Date:
Subject: Re: Bug#342369: PostgreSQL 8.1.0 RHEL / Debian incompatible