s
У вас в один поток выполняется?
Size: a a a
2020 August 20
s
При select таблица не блокируется, если у вас один коннекшен, то да, там будет складываться очередь, но если к примеру 16 потоков, то будет свободно еще 15 потоков
L
> Если там есть другие БД, их Вы тоже потеряете.
Там их нету 🙂
> Ну и вообще, см.
Спасибо за отличный список 🙂
> А зачем она партиционирована
Мне наоборот показалось с партициями будет лучше работать, но на тестах именно вставки прироста никакого нет от них, пока оставил как есть.
> А какая это версия PostgreSQL?
12, в докере крутится если что
Там их нету 🙂
> Ну и вообще, см.
Спасибо за отличный список 🙂
> А зачем она партиционирована
Мне наоборот показалось с партициями будет лучше работать, но на тестах именно вставки прироста никакого нет от них, пока оставил как есть.
> А какая это версия PostgreSQL?
12, в докере крутится если что
L
предвосхищая вопрос почему в докере - просто там docker-compose и удобнее так раскатывать на VPS для тестов, залил, потестил, грохнул впс, потом сделал новую когда надо проверить что-то другое
s
предвосхищая вопрос почему в докере - просто там docker-compose и удобнее так раскатывать на VPS для тестов, залил, потестил, грохнул впс, потом сделал новую когда надо проверить что-то другое
Не осуждаю)
YS
Привет. Не могу найти ответ на вопрос. Пусть есть бд. Есть несколько бекендов, которые хотят получить из одной таблицы данные. В таблице дофига много данных. Один запрос выполняется долго. Чтобы обеспечить множественное обращение нужно копировать записи и обращаться к копиям? ТО есть нельзя никак единовременно обратиться к одной таблице ?
Любое количество сессий может обращаться к таблице одновременно, ничего копировать не нужно... в чём у Вас проблема?
s
Yaroslav Schekin
Любое количество сессий может обращаться к таблице одновременно, ничего копировать не нужно... в чём у Вас проблема?
Скорее в одном воркере
s
И в однопоточности
L
может быть что-то ещё докрутить для массовой ставки через COPY? Индекс уберу, не подумал про Primary Key, его и потом можно)
DS
При select таблица не блокируется, если у вас один коннекшен, то да, там будет складываться очередь, но если к примеру 16 потоков, то будет свободно еще 15 потоков
Разные серверы ходят к одной БД. Спасибо, вы ответили на мой вопрос)
s
может быть что-то ещё докрутить для массовой ставки через COPY? Индекс уберу, не подумал про Primary Key, его и потом можно)
В проге все более чем хорошо
s
Напрямую в стрим постгри, все окей, лучше там хз что сделать можно)
L
без fsync = off, к слову, было ещё медленнее ))
L
но 12 часов (в лучшем случае) заливать 150 млн стро как-то.. странно что ли
s
Но в рабочей базе без fsync = off можно лишиться базы)
L
3500 строк в секунду всего выходил в среднем если посчитать, по факту там все 16 часов может быть загрузка
L
Но в рабочей базе без fsync = off можно лишиться базы)
да это понятно ) тут ж говорю что полностью пустая база и это всё оправдано
L
заливаются данные которые есть, они не критичны
s
А если в несколько потоков пустить, такое вообще возможно в данной задаче?
YS
> Если там есть другие БД, их Вы тоже потеряете.
Там их нету 🙂
> Ну и вообще, см.
Спасибо за отличный список 🙂
> А зачем она партиционирована
Мне наоборот показалось с партициями будет лучше работать, но на тестах именно вставки прироста никакого нет от них, пока оставил как есть.
> А какая это версия PostgreSQL?
12, в докере крутится если что
Там их нету 🙂
> Ну и вообще, см.
Спасибо за отличный список 🙂
> А зачем она партиционирована
Мне наоборот показалось с партициями будет лучше работать, но на тестах именно вставки прироста никакого нет от них, пока оставил как есть.
> А какая это версия PostgreSQL?
12, в докере крутится если что
> Мне наоборот показалось с партициями будет лучше работать,
Для вставки — (чуть-чуть) хуже будет работать, скорее (тратится время на выбор того, в какую partition вставлять данную запись).
> может быть что-то ещё докрутить для массовой ставки через COPY?
Так какой размер данных-то?
И Вы бы могли проверить на копировании всех подготовленных данных одним COPY (или \copy в psql), без python и разбивки на порции — потому что это покажет Вам, какой максимальной производительности можно тут добиться / к чему стремиться (т.е. будет с чем сравнить).
Для вставки — (чуть-чуть) хуже будет работать, скорее (тратится время на выбор того, в какую partition вставлять данную запись).
> может быть что-то ещё докрутить для массовой ставки через COPY?
Так какой размер данных-то?
И Вы бы могли проверить на копировании всех подготовленных данных одним COPY (или \copy в psql), без python и разбивки на порции — потому что это покажет Вам, какой максимальной производительности можно тут добиться / к чему стремиться (т.е. будет с чем сравнить).