Hello,
I have problem with VACUUM FULL on one table
Table statistics
Statistic Value
Sequential Scans455
Sequential Tuples Read114059927
Index Scans 135554861
Index Tuples Fetched152172886
Tuples Inserted 2281
Krowa Krowax wrote:
> Why vacuum full stops responding? :(
If you give it enough time (which is hard to predict and possibly more
time than you want to allow), it will probably finish, eventually. It
is, however, almost never needed or desirable to use VACUUM FULL.
I recommend you just use
Krowa Krowax writes:
> INFO: vacuuming "pg_toast.pg_toast_17929229"
> INFO: "pg_toast_17929229": found 6203 removable, 257509 nonremovable
> row versions in 20509016 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> Nonremovable row versions range from 45 to 2030 bytes long.
> There
On Mon, Oct 19, 2009 at 4:38 PM, Tom Lane wrote:
> Krowa Krowax writes:
>> INFO: vacuuming "pg_toast.pg_toast_17929229"
>> INFO: "pg_toast_17929229": found 6203 removable, 257509 nonremovable
>> row versions in 20509016 pages
>> DETAIL: 0 dead row versions cannot be removed yet.
>> Nonremovabl
On Mon, Oct 19, 2009 at 7:37 PM, Scott Marlowe wrote:
>> It's trying to repack your table in place. On the whole, I'd suggest
>> you cancel the vacuum and try a CLUSTER or some such instead.
>
> Unless that table's already in (mostly) index order, even cluster is
> gonna be pretty painful.
> I'd
Greg Stark writes:
> The run-time of CLUSTER doesn't vary very much based on whether the
> data is already in index order or not. The number of passes only grows
> like log(n) of the size of your data and if you set
> maintenance_work_mem large enough (somewhere around 100MB-1GB) the
> constants a
On Mon, Oct 19, 2009 at 8:56 PM, Tom Lane wrote:
> Greg Stark writes:
>> The run-time of CLUSTER doesn't vary very much based on whether the
>> data is already in index order or not. The number of passes only grows
>> like log(n) of the size of your data and if you set
>> maintenance_work_mem lar
Greg Stark escribió:
> On Mon, Oct 19, 2009 at 8:56 PM, Tom Lane wrote:
> > Greg Stark writes:
> >> The run-time of CLUSTER doesn't vary very much based on whether the
> >> data is already in index order or not. The number of passes only grows
> >> like log(n) of the size of your data and if you
On Tue, Oct 20, 2009 at 9:03 PM, Alvaro Herrera
wrote:
> Greg Stark escribió:
>> On Mon, Oct 19, 2009 at 8:56 PM, Tom Lane wrote:
>> > Greg Stark writes:
>> >> The run-time of CLUSTER doesn't vary very much based on whether the
>> >> data is already in index order or not. The number of passes on
