0002495: При прерывании удаления тайлов не освобождается место (СУБД)

Notes
(0014630) zed (manager) 09-09-2014 08:54	Не понимаю, чего вы хотите от нас и в чём по вашему баг SAS? Тайлы из БД удаляются? Если да, то всем остальным делом занимается базавод и SAS на него никак повлиять не может. Проверить, удаляются ли тайлы можно визуально, включив режим Только из кэша. Плюс ко всему, вы наверное не до конца читали хелп (или вернее, не сначала), на который я вам в прошлый раз давал ссылку. The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained. In contrast, VACUUM FULL actively compacts tables by writing a complete new version of the table file with no dead space. This minimizes the size of the table, but can take a long time. It also requires extra disk space for the new copy of the table, until the operation completes. The usual goal of routine vacuuming is to do standard VACUUMs often enough to avoid needing VACUUM FULL. The autovacuum daemon attempts to work this way, and in fact will never issue VACUUM FULL. И вообще, идею с освобождением места на диске, после удаления тайлов, считаю бессмысленной. БД всё равно займёт его через день, так зачем насиловать диск, выполняя полную копию таблицы? Ну не выгодно это с точки зрения производительности, поэтому все БД так поступают - однажды увеличившись в размерах уже не уменьшаются, и повторно используют пространство от удалённых записей.

(0014635) yava88 (reporter) 09-09-2014 10:53 edited on: 09-09-2014 11:34	Разобрался. Всё работает правильно. Прошу прощения за беспокойство. Кому интересно. Проделал следущее: postgresql35w=# VACUUM; VACUUM postgresql35w=# select pg_database_size('postgresql35w'); pg_database_size ------------------ 12640772612 (1 row) ---------------Запустил удаление ---------------------------------- postgresql35w=# select pg_database_size('postgresql35w'); pg_database_size ------------------ 12640883832 (1 row) ---------------5000 тайлов удалено ---------------------------------- postgresql35w=# select pg_database_size('postgresql35w'); pg_database_size ------------------ 12640883832 (1 row) postgresql35w=# VACUUM; VACUUM postgresql35w=# select pg_database_size('postgresql35w'); pg_database_size ------------------ 12640772612 (1 row) postgresql35w=# VACUUM FULL; VACUUM postgresql35w=# select pg_database_size('postgresql35w'); pg_database_size ------------------ 12581852280 (1 row) То есть только после VACUUM FULL; место высвобождается. Но не в месте дело, а в том, что удаление происходит правильно.

(0014636) vdemidov (manager) 09-09-2014 11:07	Все вопросы к автору - vasketsov. Кроме него, я больше не знаю ни одного человека, который бы этим тайлохранилищем пользовался. Я даже не представляю как его настраивать, поэтому и просил написать в вики статью, раз уж у вас получилось его настроить.

(0014637) zed (manager) 09-09-2014 11:21	А так может просто не выполняется commit, если процесс насильственно прерван. Такое вполне может быть. По поводу структуры я вам точно не подскажу, но судя по мыслям, что высказывались в тикете, где обсуждалось сознание этого хранилища, в БД применяется разбиение таблиц по принципу как в Беркли сделано разбиение по файлам sdb. Только в беркли бъётся квадратами по 256*256 тайлов, а в СУБД можно настраивать размер ячейки. Ну или можно хранить всё в одной таблице. Сами тайлы хранятся вот в таких таблицах: create table "%Z%%HX%%DIV%%HY%_%SVC%" ( x numeric not null, y numeric not null, id_ver smallint not null, tile_size int default 0 not null, id_contenttype smallint not null, load_date TIMESTAMP default CURRENT_TIMESTAMP not null, tile_body bytea null, constraint PK_%Z%%HX%%DIV%%HY%_%SVC% primary key (x, y, id_ver) ) ; (вместо переменных внутри %% подставляются конкретные значения). С X и Y в качестве полей там больше и таблиц-то нету, как вы могли их не заметить?

(0014638) zed (manager) 09-09-2014 11:26	> Я даже не представляю как его настраивать Элементарно: 0001113:0010146

(0014639) vdemidov (manager) 09-09-2014 11:36	>Элементарно Ну так добавь это описание в вики.

(0014640) yava88 (reporter) 09-09-2014 11:38	Разобрался. Всё работает правильно. Прошу прощения за беспокойство. vdemidov, да напишу. Работать оно еще 3 дня назад начало, а вот понимание только сейчас приходит.

(0014641) zed (manager) 09-09-2014 11:38	Ну так сам добавь.

Users who viewed this issue
User List	Anonymous (1828x), k-dmitriy (1x)
Total Views	1829
Last View	22-11-2024 03:31

Issue History
Date Modified	Username	Field	Change
09-09-2014 07:33	yava88	New Issue
09-09-2014 07:35	yava88	Note Added: 0014627
09-09-2014 08:26	vdemidov	Steps to Reproduce Updated	View Revisions
09-09-2014 08:27	vdemidov	Note Deleted: 0014627
09-09-2014 08:27	vdemidov	Assigned To	=> vasketsov
09-09-2014 08:27	vdemidov	Status	new => assigned
09-09-2014 08:54	zed	Note Added: 0014630
09-09-2014 10:53	yava88	Note Added: 0014635
09-09-2014 11:05	yava88	Note Edited: 0014635	View Revisions
09-09-2014 11:07	vdemidov	Note Added: 0014636
09-09-2014 11:21	zed	Note Added: 0014637
09-09-2014 11:26	zed	Note Added: 0014638
09-09-2014 11:34	yava88	Note Edited: 0014635	View Revisions
09-09-2014 11:36	vdemidov	Note Added: 0014639
09-09-2014 11:38	yava88	Note Added: 0014640
09-09-2014 11:38	zed	Note Added: 0014641
10-09-2014 07:18	zed	Status	assigned => closed
10-09-2014 07:18	zed	Assigned To	vasketsov =>
10-09-2014 07:18	zed	Resolution	open => no change required

Relationships

SASGIS