Re: PostGreSQL 8.1.0 : out of memory during vacuum full
От | DANTE ALEXANDRA |
---|---|
Тема | Re: PostGreSQL 8.1.0 : out of memory during vacuum full |
Дата | |
Msg-id | 439EEF43.5020905@BULL.NET обсуждение исходный текст |
Ответ на | PostGreSQL 8.1.0 : out of memory during vacuum full analyze (DANTE ALEXANDRA <ALEXANDRA.DANTE@BULL.NET>) |
Список | 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 по дате отправления: