место ты, правда, таким стиранием на диск не вернёшь

мне только логический объем уменьшить надо.

можно хоть под psql -c в цикле держать

+100500

мы переносить ее будем и версию postgres поднимать, там будет даунтайм уже

а почему диск не уменьшится?

вакуум же потом освободит

если на ней индексы есть, то вакуум будет больно

ну вроде как full wacum нужен

чтобы место высвободить

вакуум освободит из конца, а в конец всё дописывается

а передвинуть тапл между страничками у постгреса кроме как cluster и vacuum full надёжных сценариев, кажется, нет

мы напоролись, что вакуум на больших таблицах всегда перебирает индексы целиком, и иногда это начинает быть минутами

то есть на больших таблицах лучше сразу партиции делать?

на вырост. так?

чтобы потом не страдать

вообще, лучше бы постгрес починить в этом плане

ну починить я точно не смогу, а вот сена подложить да

но да, мы тут стали по гигабайту резать

до того резали по суткам, чтобы стирать удобно было

а вообще, delete from table where ctid in (select ctid from table where date > now()-interval '1 day' limit 1000)

ну вообще как то не айс cdrdb=# explain delete from ops_history where ctid in (select ctid from ops_history where age(to_timestamp(ops_history.clock)) > interval '21 days' limit 10); QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------ Delete on ops_history (cost=0.00..408793982.76 rows=10 width=36) -> Nested Loop Semi Join (cost=0.00..408793982.76 rows=10 width=36) Join Filter: (public.ops_history.ctid = "ANY_subquery".ctid) -> Seq Scan on ops_history (cost=0.00..41378186.35 rows=2449438635 width=6) -> Materialize (cost=0.00..1.18 rows=10 width=36) -> Subquery Scan on "ANY_subquery" (cost=0.00..1.13 rows=10 width=36) -> Limit (cost=0.00..1.03 rows=10 width=6) -> Seq Scan on ops_history (cost=0.00..84243362.46 rows=816479545 width=6) Filter: (age((('now'::cstring)::date)::timestamp with time zone, to_timestamp((clock)::double precision)) > '21 days'::interval) (9 rows)

и весит уже минут 5

на 10ти записях

а если взять какой-нибудь другой id?

Да, та же фигня была

Делал удаления по ctid в таблице на 1 млн -- очень долго работало.

age(ts)>'21 days' не ускорится индексом

C#, у меня тут такого нет

Вроде, в NPgsql был не плохой встроенный пул. И он плохо дружил с pg_bouncer.

Вроде, в NPgsql был не плохой встроенный пул. И он плохо дружил с pg_bouncer.

он _очень_ плох

если его нагрузить немного, то драйвер начинает кашлять

cdrdb=# select ctid from ops_history where age(to_timestamp(ops_history.clock)) > interval '21 days' limit 10; ctid -------------- (3351904,1) (3351904,2) (3351904,3) (3351904,4) (3351904,5) (3351904,6) (3351904,7) (3351904,8) (3351904,9) (3351904,10) (10 rows) Time: 0.459 ms cdrdb=#

а селектом быстро выстаскивает все

ага, по = и limit 1 будет tid scan

where ctid in ('(0,0)', '(1,1)'); даёт tid scan

я не знаю, как сделать tid scan с подзапросом

можно сделать генератор делитов с прошитым списком tid

Привет. Есть большая таблица, в ней очень много записей(500гб), хочется удалить все старше N-дней. хотел открыть курсор, удалить 100000 записей сделать коммит и так в цикле, но на сколько я понял postgresql это сделать не получится (https://stackoverflow.com/questions/2305431/commit-in-postgresql-stored-procedure). Посоветуйте решение проблемы (без create table / drop table / rename table)

Я давно в версии 8.2 делал транзакцию в транзакции с помощью db_link

а нет хинта который принудительно включает Seq Scan

?

psql -c "copy (select 'delete from ops_history where id in ('' ' || string_agg(ctid, ''',''')' || ' )'' ');' from ops_history where clock > extract(epoch from now() - interval '21 days') to stdout with csv header" | psql

кавычки править, пока не заработает

вообще огонь! спасибо

только учитывай, что нужно держать баланс между размером стираемой области и временем выполнения запроса

потому что ты начнёшь на seq scan стирать таблицу с начала, и на повторных seq scan он будет проходить по страничкам, в которых всё уже удалено, с каждым разом всё медленнее выполняя запрос

хотя, если у тебя параллельно крутится какой-то ещё seq scan, то synchronized seq scan начнёт тебе скан не с нуля, рандомизируя этот фактор