
Petr
22.04.2018
15:14:43
так не поможет же
там в .sql не набор UPDATE на каждую строку, а один только

Darafei
22.04.2018
15:15:37
господа,
делается некоторый UPDATE по строкам с ID на отрезке A..B., делается он через psql, просто подцепив .sql файл с данным запросом
вопрос: можно ли (по меньшей мере, с какой-то погрешностью) определить, на какой строке сейчас "работает" данный процесс, при условии, что идёт он в один поток?
также следует отметить, что никаких измениний в данный процесс сделать уже нельзя (добавить трек-секвенции и т.д.)
разумеется, я не собираюсь отслеживать прогресс постоянно, я хочу посмотреть туда скажем раз в 12 часов
gdb и поглядывать внутрь сервера?

Andrey
22.04.2018
15:15:41
Где-то был экстеншен для этого. Pg query state или как-то так. Работает только с патченным пг

Google

Petr
22.04.2018
15:16:00

Darafei
22.04.2018
15:16:03
да, или так

Petr
22.04.2018
15:16:07

Darafei
22.04.2018
15:16:37
как это сделать? :)
я никогда не помню и начинаю путь каждый раз с https://poormansprofiler.org/

Dmitrii
22.04.2018
15:16:46
Всем привет, вопрос больше по архитектуре баз данных. Как вы считаете, правильно ли добавлять поле user_id в каждую таблицу объект которой может быть прямо или косвенно быть создан пользователем? Даже несмотря на то что если между таблицами уже есть связь, и в теории пользователя и так можно было бы узнать.

Petr
22.04.2018
15:17:19

Dmitrii
22.04.2018
15:17:20
Но например потребовалось бы сделать 1, 2 или 3 джойна.

Darafei
22.04.2018
15:17:25

Dmitrii
22.04.2018
15:17:50

Darafei
22.04.2018
15:18:14
несмотря на запросы мало что вообще можно советовать
несмотря на запросы - должно хватать нормальных форм :)

Dmitrii
22.04.2018
15:19:12
Т.е. считаешь что не стоит так делать?
Вот кейс, есть User -> Partner -> Preferences -> LocationData

Google

Darafei
22.04.2018
15:19:59
считаю, что при денормализации нужно смотреть в запросы

Dmitrii
22.04.2018
15:20:06
На данный момент у меня даже в LocationData есть user_id. Вроде как удобно

Darafei
22.04.2018
15:20:41
а что делать, когда он разъезжается?
а как это совместимо с GDPR?

Dmitrii
22.04.2018
15:21:06
Но это же user_id. Он никогда не меняется.

Darafei
22.04.2018
15:21:25
очень смелое заявление
как минимум GDPR может знатно пошатать это предположение

Dmitrii
22.04.2018
15:22:04
В любом случае даже для FK есть каскадное обновление

Dmitry
22.04.2018
15:22:11
а конфиги логов меняются через SET?

Dmitrii
22.04.2018
15:22:20
А вы так смело про GDPR говорите, у вас на практите или в теории?

Darafei
22.04.2018
15:22:47

Petr
22.04.2018
15:24:31
а можно выполнение скрипта в psql поставить на паузу? (не через дебаггер)

Dmitrii
22.04.2018
15:24:43
Ну так GDPR это про персональные данные. Если данные уже в базе, то вы уже выполняете GDPR грубо говоря
Подвязать к таблице id — ничего не менет по сути
Данные как можно было связать до этого так и осталась возможность.

Darafei
22.04.2018
15:25:30
больше мест, откуда надо не забыть вытереть

Dmitrii
22.04.2018
15:25:59
id пользователя не относится к персональным данным.

Maksim
22.04.2018
15:26:02

Darafei
22.04.2018
15:26:18
а если там ещё и fk на юзера - то на каждом трогании перепроверять, есть такой или уже нет

Google

Petr
22.04.2018
15:27:01

Maksim
22.04.2018
15:30:10

Petr
22.04.2018
15:31:30
у меня пропаченная Книжником 9.6-stab, к сожалению не от postgrespro

Dmitry
22.04.2018
15:35:08
на самом деле нефига, настройки логов прекрасно меняются через SET... ну само собой те, которые не требуют рестарта, а оно вроде только одно такое - logging_collector

Nikita
22.04.2018
15:36:27

Dmitry
22.04.2018
15:49:01
господа,
делается некоторый UPDATE по строкам с ID на отрезке A..B., делается он через psql, просто подцепив .sql файл с данным запросом
вопрос: можно ли (по меньшей мере, с какой-то погрешностью) определить, на какой строке сейчас "работает" данный процесс, при условии, что идёт он в один поток?
также следует отметить, что никаких измениний в данный процесс сделать уже нельзя (добавить трек-секвенции и т.д.)
разумеется, я не собираюсь отслеживать прогресс постоянно, я хочу посмотреть туда скажем раз в 12 часов
приделай тригер с логированием ;)

Petr
22.04.2018
15:49:28

Dmitry
22.04.2018
15:49:37
мммм... разве?

Petr
22.04.2018
15:50:24
разве нет? upd: хотя, возможно вы и правы, сейчас уточню

Dmitry
22.04.2018
15:50:36
если навесишь на таблицу 'AFTER UPDATE ON .. FOR EACH ROW' в другой сессии...

Darafei
22.04.2018
15:52:57
ddl же транзакционный, как триггер в чужую транзакцию засунется?

Petr
22.04.2018
15:55:53
а как из gdb потом безопасно выйти чтобы он не отправил SIGKILL или что-нибудь такое постгресу?

Dmitry
22.04.2018
16:04:06
да, CREATE TRIGGER требует лока таблицы
я бы, конечно, strace глянул сначала, чем gdb...

Petr
22.04.2018
16:21:29

Dmitry
22.04.2018
16:24:16
ps xa находим процесс постгреса, который занимается вами сейчас
и strace -fF -s 500 -p <pid>
хотя что вы там увидите... это вопрос

Google

Petr
22.04.2018
16:25:28
сейчас попробую
если я strace через ctrl+C вырублю, он не сломает мне постгрес?)

Dmitry
22.04.2018
16:32:05
не

Petr
22.04.2018
16:33:42
ну, там видно lseek, read и kill
если я не ошибаюсь, эти функции мне вряд-ли подскажут какая сейчас строка текущая
upd: хотя... через read сейчас попробую
@miksir преобразовав эти несчастные char'ы к читабельному виду нашел таки там id'шник строки, спасибо)

Dmitry
22.04.2018
17:00:59
чудно...

Petr
22.04.2018
17:01:51
ну так там в read весь тапл видно (ну или не весь, в общем случае не скажу)
только для меня увидительно что idшники идут не последовательно (хотя поток, по идее, один)
это можно как-то объяснить?)

Dmitry
22.04.2018
17:15:07
ну а с чего бы им идти по порядку... думаю они по физическому расположению идут

Petr
22.04.2018
17:16:04
в таком случае у меня затруднения с тем чтобы определить прогресс)
причем он лихо достаточно шагает туда-сюда

Dmitry
22.04.2018
17:25:11
и скорость не посчитать - strace все же подсаживает скорость основного процесса... хз насколько

Petr
22.04.2018
17:25:32
уверен что порядочно

Darafei
22.04.2018
17:25:52
если seq scan, то скорость можно из смещений высчитать

Petr
22.04.2018
17:28:14
seq scan, да
о каких смещениях идет речь?

Darafei
22.04.2018
17:29:40
от начала файла, в seek

Petr
22.04.2018
17:32:21
по какой же формуле считается оное? не могу прикинуть
lseek(565, 351518720, SEEK_SET) = 351518720
lseek(565, 351674368, SEEK_SET) = 351674368 (d = 155648)
lseek(565, 351535104, SEEK_SET) = 351535104 (d = 139264)
lseek(565, 351715328, SEEK_SET) = 351715328 (d = 180224)
lseek(565, 351567872, SEEK_SET) = 351567872 (d = 147456)
lseek(565, 351797248, SEEK_SET) = 351797248 (d = 229376)

Google

Dmitry
22.04.2018
17:34:48
это если where нет... а если where и seq scan то тоже прогресс сложно будет оценить

Petr
22.04.2018
17:36:50
where есть, ага :(

Andiskiy
23.04.2018
08:53:46
Есть определенный набор записей где содержится поле типа float , и я хотел бы знать как можно проверить существует ли в этом поле число которое содержит десятичную часть числа? Rails, Postgres.
было бы хорошо, если бы это можно было получить одним запросом (AR + PG). Помогите пожалуйста.

Yaroslav
23.04.2018
08:58:54

Arman
23.04.2018
09:00:15
Речь об этом, наверное. https://stackoverflow.com/questions/3418606/sql-how-do-i-get-only-the-numbers-after-the-decimal

Andiskiy
23.04.2018
09:02:36

Гаврилов
23.04.2018
09:03:43
остаток от деления на еденицу?)))

Andiskiy
23.04.2018
09:04:26

Darafei
23.04.2018
09:04:38

Yaroslav
23.04.2018
09:04:39

Darafei
23.04.2018
09:04:44
это всё-таки float

Гаврилов
23.04.2018
09:05:34
а еще можно конвертить в int и обратно

Andiskiy
23.04.2018
09:05:37