@pgsql

Страница 773 из 1062
Petr
22.04.2018
15:14:43
так не поможет же

там в .sql не набор UPDATE на каждую строку, а один только

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

Google
Petr
22.04.2018
15:16:00
Где-то был экстеншен для этого. Pg query state или как-то так. Работает только с патченным пг
проблема в том, что процесс уже идёт, нужно как-то "на горячую" :)

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 в каждую таблицу объект которой может быть прямо или косвенно быть создан пользователем? Даже несмотря на то что если между таблицами уже есть связь, и в теории пользователя и так можно было бы узнать.

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

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
а конфиги логов меняются через SET?
или в конфиг-файле, или в alter system

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 пользователя не относится к персональным данным.

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

Google
Petr
22.04.2018
15:27:01
можно выполнить pg_sleep
спасибо) upd: только в рантайме вроде не получится

Maksim
22.04.2018
15:30:10
спасибо) upd: только в рантайме вроде не получится
pg_query_state встроенный если что имеется в postgrespro сборке

спасибо) upd: только в рантайме вроде не получится
ну тут надо отдельным запросом (или подзапросом) оформлять

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
а как это совместимо с GDPR?
GDPR только для стран-участников ЕС, так?

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
я бы, конечно, strace глянул сначала, чем gdb...
Не подскажите, как это сделать (или куда ткнуть на источник) ? А то боюсь сломать текущий запрос

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). Помогите пожалуйста.

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
А что такое "содержит десятичную часть числа" ? "trunc(col) <> col"?
1.1 , 4.22 - содержит десятичную часть. 1.0 , 4.0 - не содержит десятичную часть.

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

Andiskiy
23.04.2018
09:04:26
остаток от деления на еденицу?)))
да, как средствами PG это получить?)

Darafei
23.04.2018
09:04:38
1.1 , 4.22 - содержит десятичную часть. 1.0 , 4.0 - не содержит десятичную часть.
а 1.0000000000000000001 содержит десятичную часть? а 0.99999999999999999997?

Yaroslav
23.04.2018
09:04:39
1.1 , 4.22 - содержит десятичную часть. 1.0 , 4.0 - не содержит десятичную часть.
Ну так с виду написанное мной выражение подходит... Или у вас не в этом проблема?

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

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

Andiskiy
23.04.2018
09:05:37
Ну так с виду написанное мной выражение подходит... Или у вас не в этом проблема?
подходит. но я бы хотел знать чем отличается вот от этого (col - CAST(col as Integer)) <> 0

Страница 773 из 1062