@pgsql

« Назад

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

Далее »

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

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

проблема в том, что процесс уже идёт, нужно как-то "на горячую" :)

Darafei

22.04.2018
15:16:03

да, или так

Petr

22.04.2018
15:16:07

gdb и поглядывать внутрь сервера?

как это сделать? :)

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

я никогда не помню и начинаю путь каждый раз с https://poormansprofiler.org/

спасибо!

Dmitrii

22.04.2018
15:17:20

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

Darafei

22.04.2018
15:17:25

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

нужно смотреть на типичные запросы и от них отталкиваться.

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

А вы так смело про GDPR говорите, у вас на практите или в теории?

в основном в застольных беседах

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

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

можно выполнить pg_sleep

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

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

ddl же транзакционный, как триггер в чужую транзакцию засунется?

:( gdb так gdb

а как из 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

и скорость не посчитать - strace все же подсаживает скорость основного процесса... хз насколько

а какой план у апдейта?

если 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

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

А что такое "содержит десятичную часть числа" ? "trunc(col) <> col"?

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 - не содержит десятичную часть.

Гаврилов