vacuum full если что.

остальное и автовакуум спокойно делает

он копию индекса наверно делает, с которой работают пока он дропается)

EPIC FAIL )

вакуумы, дропы, еще на цепь посадили и заставляют этим постгресом пользоваться )

уберите еду!

в некоторых организациях люди в ожидании окончания вакуумов и дропов вынуждены спать на полу серверной в ожидании результата

vacuum full если что.

так ли вам нужен vacuum full? если да - переключайте мастер

EPIC FAIL. Может, еще заодно поворачивать каждый раз стартовый стол космодрома?

кстати, раз уж мы тут об эксклюзивных операциях говорим - как там себя mysql на alter table add column чувствует? Когда таблица хотя бы гигов сто?

Мы такое выполняем на терабайтных базах и не грустим

в некоторых организациях люди в ожидании окончания вакуумов и дропов вынуждены спать на полу серверной в ожидании результата

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

петабайт на смартфоне у него с мускулом и поэтессами

Мы такое выполняем на терабайтных базах и не грустим

на живом mysql и при записи в alter-рируемую таблицу? чегой-то не верится

основные неприятности случаются когда колонке явно сказано NOT NULL

Мы такое выполняем на терабайтных базах и не грустим

с включенным ACID хоть?

Stanislav, на коё чёрт вам vacuum full понадобился? И чем вы ещё постгрес грузили, когда делали drop index concurrently ?

немного не про mysql, новости рус постгрес сообщества: в ближайшее время будет сразу несколько событий. Часть из них будут в режиме «только онлайн» (a.k.a webinar, a.k.a. online meetup) — так что в них можно будет участвовать независимо от географии Группа переименована в #RuPostgres, так короче Открыта регистрация на вебинар от организаторов PgDay.ru, состоится 22.09 19:00 MSK. Записывайтесь: http://www.meetup.com/postgresqlrussia/events/234170306/ Ну а 4.10 в Москве соберёмся вот уже в третий раз в офисе Яндекса. Поговорим о pl/pgsql, версионности кода и тестах. Подробности на страничке группы, регистрация откроется совсем скоро. PostgresPro про Postgres 9.6 вчера подробно рассказали в ГАИШ, есть видео: https://www.youtube.com/watch?v=pFBqR8QqdvY Кроме этого, на подходе ещё несколько митапов. Ну а на юбилейном 10-м Highload++ (http://highload.ru) в этом ноябре Postgres будет представлен ещё более мощно, чем когда-либо ранее. Будет отдельная PostgreSQL-секция и целый ряд компаний. \x

Блин, а почему drop index в постгри настолько дорогая операция?

нашли в чём дело?

в теории там всё быстро если только у вас нету много длинных транзакций на таблицу.

Нагрузка 3000 TPS

idle in transaction нет, но сессии очень длинные, непрерывно валящие транзакцию за транзакцией

соотношение I/U/D примерно 1/2/1

приглашаю эксперта по индексам

ого, теперь наверно все или почти все эксперты тут)

надо плату за вход на канал собирать )

всем привет

если денюшка на общее благо, то я согласен!

Нагрузка 3000 TPS

а версия постгреса какая?

9.4.9

Stanislav, на коё чёрт вам vacuum full понадобился? И чем вы ещё постгрес грузили, когда делали drop index concurrently ?

drop index concurently до недавнего времени хорошо так аффектил реплику

размер индекса 5GB

да, реплику прикладывает

но на нее как-то пофигу

9.4.9

сессии длинные?

да, многочасовой длины

в смысле pool в апликейшене или где?

транзакции - короткие очень

да, в приложухе

я думаю что дело где-то в стороне кэша релейшенов и индексов

индекс с таблички размером 60GB

пара интов буквально в нем

сколько объектов в базе?

глобально?

или релейшенов сколько?

ну да +/-

тебе релейшены или все ряды подсчитать по базе?

объектов (таблиц/индексов) - бешеное кол-во или нет?

бешенное от 100k

1044 таблицы по всем схемам в сумме

а пул все таки в апликейшене или в pgbouncer или еще где?

Нет никаких пгпулов и баунсеров. В приложухе все. Приложуха живет вечно.

Она сама выбирает мастер и реплики

Точнее там десяток приложух и сотня воркеров этих приложух если в тоталс переводить

Но они используют один и тот же код для работы с базой

посмотреть бы где бакенд висит когда drop index идет gdb —pid $pid_of_backed —ex bt —batch

ок, спасибо

если покажешь - может помогу :(

ребят

подскажите такой вопрос

есть запрос с кабинета

но выглядит как несколько и после получения результатов

не убивается

сам

посмотреть бы где бакенд висит когда drop index идет gdb —pid $pid_of_backed —ex bt —batch

no debugging symbols found dbg пакетов в штатной дебианорепе нет.

а дальше что?

root@by01-pgsql02:~# gdb —pid 14139 —ex bt —batch [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f6188d4ad20 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. #0 0x00007f6188d4ad20 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f618ac4fb63 in WaitLatchOrSocket () #2 0x00007f618abdf6d3 in secure_read () #3 0x00007f618abe91d8 in ?? () #4 0x00007f618abe9d95 in pq_getbyte () #5 0x00007f618acbbb93 in PostgresMain () #6 0x00007f618aa55dad in ?? () #7 0x00007f618ac5ffac in PostmasterMain () #8 0x00007f618aa56f37 in main ()

последние строки: Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2 0x00007fa3224b6057 in semop () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb)

Делал так: gdb —pid 19890 —ex bt —batch

https://gist.githubusercontent.com/vadv/3de66ee616d826d8ce249e435a79533e/raw/8237475d4c1ee0c3ec3905dbf496d59d8458be6a/gistfile1.txt

может испортил telegram

попробуй из gist (pid должен принадлежать бакэнду postgresql)

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

подскажите, вот я переношу бекап с сервера на сервер. на исходном сервере все еще работает аппа, которая иногда пишет-читает данные, которые мне не страшно потерять. бекап таким образом будет дольше передаваться, или оно не влияет?

Если на таблице два одинаковых индекса, возможна ли ситуация, что планировщик будет иногда пользоваться второй копией, тем самым "балансируя" нагрузку / локи между ними?

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

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

тупо по физической сортировке в pg_class

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

тут речь про другой

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

про drop наверно

нет, это отдельно от дропа вопрос

то что по статистике больше подходит то и использует

на эту таблицу дроп еще не добрался

у нас там очередь на дропы на несколько суток. В среднем 10 часов на дроп маленького индекса и двое суток на полновесный индекс уходит.

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

Спасибо, я знаю.

какие-то сумасшедшие числа :(

а зачем вообще дропать индексы!?

а зачем вообще дропать индексы!?

Разработчики понасоздают всякого разного, а потом удивляются - чего это экземпляр СУБД люто тормозит.

Смотришь, а там дублирующих индексов - вагон и маленькая тележка

надо просто сразу понимать СУБД не предназначина на постоянное изменении схемы. т.е. при всех плюшках postgres это всё же не самая штатная ситуация. Схема должна быть достаточно стабильна.

это может быть в ходе эксперимента и не всегда есть возможность корректно это оценить на стейджинге

Юр, разработчики всякого прикладного - это такие забавные ребята...

разработчики виноваты

Юр, разработчики всякого прикладного - это такие забавные ребята...

я в первую очередь такой разработчик... :(