From: | "Gabriele Bartolini" <g(dot)bartolini(at)comune(dot)prato(dot)it> |
---|---|
To: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | VACUUM FULL ANALYSE hanging |
Date: | 2007-05-02 10:05:33 |
Message-ID: | 910CF843580B3C40A25CD0D04B3908E213050E@exchange4.comune.prato.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi guys,
I am having problems with freeing disk space after a massive delete operation on a table that had approximately 80 million record. I ran the following command, by setting the vacuum memory to approximately a GigaByte:
SET vacuum_mem TO 1024000
VACUUM FULL ANALYSE VERBOSE oltp.requests
Here is what I get:
There were 34221203 unused item pointers.
Total free space (including removable row versions) is 8969616624 bytes.
1129827 pages are or will become empty, including 0 at the end of the table.
1337307 pages containing 8964065020 free bytes are potential move destinations.
CPU 16.03s/9.12u sec elapsed 219.47 sec.
INFO: index "requests_pkey" now contains 20075362 row versions in 327419 pages
DETAIL: 8211835 index row versions were removed.
217782 index pages have been deleted, 217782 are currently reusable.
CPU 5.38s/12.53u sec elapsed 100.80 sec.
INFO: index "idx_oltp_requests_access_date" now contains 20075362 row versions in 491725 pages
DETAIL: 8211835 index row versions were removed.
426501 index pages have been deleted, 426501 are currently reusable.
CPU 14.96s/13.47u sec elapsed 200.91 sec.
INFO: index "idx_oltp_requests_access_time" now contains 20075362 row versions in 343915 pages
DETAIL: 8211835 index row versions were removed.
213612 index pages have been deleted, 213612 are currently reusable.
CPU 6.32s/14.03u sec elapsed 111.24 sec.
INFO: index "idx_oltp_requests_referer" now contains 20075362 row versions in 470822 pages
DETAIL: 8211835 index row versions were removed.
376873 index pages have been deleted, 376873 are currently reusable.
CPU 18.85s/17.18u sec elapsed 265.25 sec.
INFO: index "idx_oltp_requests_session" now contains 20075362 row versions in 611141 pages
DETAIL: 8211835 index row versions were removed.
478827 index pages have been deleted, 478827 are currently reusable.
CPU 16.83s/14.33u sec elapsed 258.47 sec.
INFO: index "idx_oltp_requests_status_code" now contains 20075362 row versions in 690337 pages
DETAIL: 8211835 index row versions were removed.
600953 index pages have been deleted, 600953 are currently reusable.
CPU 34.37s/24.44u sec elapsed 297.21 sec.
INFO: index "idx_oltp_requests_url" now contains 20075362 row versions in 336075 pages
DETAIL: 8211835 index row versions were removed.
73821 index pages have been deleted, 73821 are currently reusable.
CPU 17.06s/28.14u sec elapsed 319.16 sec.
But here, the command simply hangs.
The table description is:
htminer=> \d oltp.requests
Tabella "oltp.requests"
Colonna | Tipo | Modificatori
--------------------+-----------------------------+--------------------
id_request | integer | not null
id_session | integer |
access_time | timestamp(0) with time zone | not null
request_method | numeric(2,0) | not null default 1
http_version_major | numeric(1,0) | not null default 1
http_version_minor | numeric(1,0) | not null default 1
status_code | numeric(3,0) | not null
bytes | integer |
time_taken | numeric(3,0) |
id_url | integer | not null
id_referer | integer |
content_language | character(2) |
dwell_time | smallint | not null default 1
request_type | numeric(1,0) |
Indici:
"requests_pkey" PRIMARY KEY, btree (id_request), tablespace "htminer_oltp"
"idx_oltp_requests_access_date" btree (date_trunc('day'::text, timezone('UTC'::text, access_time))), tablespace "htminer_oltp"
"idx_oltp_requests_access_time" btree (access_time), tablespace "htminer_oltp"
"idx_oltp_requests_referer" btree (id_referer), tablespace "htminer_oltp"
"idx_oltp_requests_session" btree (id_session, status_code), tablespace "htminer_oltp"
"idx_oltp_requests_status_code" btree (status_code), tablespace "htminer_oltp"
"idx_oltp_requests_url" btree (id_url), tablespace "htminer_oltp"
Vincoli di controllo:
"requests_bytes_check" CHECK (bytes >= 0)
"requests_dwell_time_check" CHECK (dwell_time >= 0)
"requests_id_request_check" CHECK (id_request > 0)
"requests_request_method_check" CHECK (request_method > 0::numeric)
"requests_request_type_check" CHECK (request_type > 0::numeric)
Vincoli di integrità referenziale
"requests_id_referer_fkey" FOREIGN KEY (id_referer) REFERENCES oltp.urls(id_url) ON UPDATE CASCADE ON DELETE CASCADE
"requests_id_session_fkey" FOREIGN KEY (id_session) REFERENCES oltp.sessions(id_session) ON UPDATE CASCADE ON DELETE CASCADE
"requests_id_url_fkey" FOREIGN KEY (id_url) REFERENCES oltp.urls(id_url) ON UPDATE CASCADE ON DELETE CASCADE
Tablespace: "htminer_oltp"
Should I drop the indexes and re-create them?
Thanks,
Gabriele
--
Gabriele Bartolini - Istruttore Informatico - Comune di Prato
Sistema Informativo - Servizi di E-Government e Open-Source
g(dot)bartolini(at)comune(dot)prato(dot)it - www.comune.prato.it <http://www.comune.prato.it/> - www.htminer.it <http://www.htminer.it/>
From | Date | Subject | |
---|---|---|---|
Next Message | Sandy Spence | 2007-05-02 10:55:51 | pg_user pg_shadow out of sync |
Previous Message | Thomas Markus | 2007-05-02 08:33:46 | infinite blocking statements in 8.2.3 |