
Terminator
29.08.2018
07:10:26
@Valentinishe будет жить. Поприветствуем!

Виктор
29.08.2018
07:20:12
"Поменял ФИО сотруднику, ФИО сразу меняется и в таблице платежей."
Это реляционное свойство, при чем здесь форинкеи?

Yaroslav
29.08.2018
07:22:35

Anton
29.08.2018
07:24:38

Google

Anton
29.08.2018
07:26:21
Хеш - тут неправильно выразился. Название файла 0000010000000....

Vadim
29.08.2018
07:32:59
Вопрос. Возможно ли как то sql запросом реализовать уникальность значений полей. Но с кое какой оговоркой. Например есть 2 колонки с айдишниками пользователей. Допустим в ней 20 отовых строк. В каждой колонке айдишники могут повторяться. Возьмем 3 строки. userID userID2 (1, 2, 1) (3, 2, 4). Так вот. Мне нужно сделать новую таблицу с одной колонкой userID. и в нее поместить неповторяющиеся поля с первой и второй колонки. Из данного примера должна она заполняться так. 1, 2, 4. Тоесть первые два берутся с первой колонки. А последний берутся со второй, так как с первой идет поворение
Очень специфичная задача

Yaroslav
29.08.2018
07:33:43

Anatoly
29.08.2018
07:37:09
ФК даст простую схему - нельзя создать платеж на несуществующего пользователя

Eugeny
29.08.2018
07:39:07

Vadim
29.08.2018
07:40:16
спасибо, попробую

Ivan
29.08.2018
07:42:23

Vadim
29.08.2018
07:43:13
та приоритет идет с первой колонки. Если же уже есть повторение, то берется со второй
закрученая логика. ДЕлаем миграцию

Zamira
29.08.2018
07:47:05
Вопрос. Возможно ли как то sql запросом реализовать уникальность значений полей. Но с кое какой оговоркой. Например есть 2 колонки с айдишниками пользователей. Допустим в ней 20 отовых строк. В каждой колонке айдишники могут повторяться. Возьмем 3 строки. userID userID2 (1, 2, 1) (3, 2, 4). Так вот. Мне нужно сделать новую таблицу с одной колонкой userID. и в нее поместить неповторяющиеся поля с первой и второй колонки. Из данного примера должна она заполняться так. 1, 2, 4. Тоесть первые два берутся с первой колонки. А последний берутся со второй, так как с первой идет поворение
Почему не 1,2,3,4? 3 ведь тоже не повторяется

Vadim
29.08.2018
07:47:35
ну я ведь привел 3 записи. А значит в другой таблице должно быть 3 записи. Все идет последовательно

Google

Zamira
29.08.2018
07:51:35
Хм... теперь поняла. Задачу поняла. В результате должно быть столько же значений, сколько записей. Но ведь row_number и вытаскивание по having row_number =1 вовсе не гарантиует столько значений сколько записей

Eugeny
29.08.2018
07:54:10
)))

Vadim
29.08.2018
07:54:42
братиш, если оно, расцелую. Сек
посмотрю

Eugeny
29.08.2018
07:55:19
я просто привык, что когда ко мне обращаются по повторениям, то там что то более сложное

Vadim
29.08.2018
07:58:04
не, не правильно работает
оно склеивает много лишних колонок

Zamira
29.08.2018
08:07:18
По моему тут sql запросом не обойтись. Каждое значение результирующего userID зависит от разного количества других записей. При этом количество записей остается неизменным.
Кстати, а что если (1, 2, 1, 1)? (4, 3, 4, 4)? Какой результат должен быть?
1 и 4 уже использовал. Как быть с третей записью, где опять 1 и 4 используется?

Vadim
29.08.2018
08:14:12
такого не будет. Данное явление уже отфильтровано.

Yaroslav
29.08.2018
08:15:03
не, не правильно работает
А как правильно? Пояснили бы Вы ещё, что именно Вам нужно.
> Если же уже есть повторение, то берется со второй
Здесь какой-то порядок подразумевается? Или нет?

Dmitry
29.08.2018
08:32:47
привет! а кто может поделиться инфой про upgrade "ванильной" версий postgresql на aws?

Darafei
29.08.2018
08:33:20

Dmitry
29.08.2018
08:33:25
угу

Darafei
29.08.2018
08:33:30
кнопочка в админке

Dmitry
29.08.2018
08:33:50
это понятно, просто сколько времени она может занять? :)
даунтайма :)
здесь есть на несколько tb база и хочется все таки понять сколько времени это будет занимать.
понятно что pg_upgrade- быстрая утилита, но именно со спецификой aws

Darafei
29.08.2018
08:36:00
можешь отцепить реплику и заапгрейдить реплику

Google

Darafei
29.08.2018
08:36:43
гигов 50 апгрейдилось в пределах 5 минут

Dmitry
29.08.2018
08:37:54

Kirill
29.08.2018
08:39:08
https://paste.fedoraproject.org/paste/Kx232taXGCZl7M06Z~0agQ
кто подскажет на что обратить внимание? отрабатывает долго
каунты отжирвает основное время, ну и групировка немного

Eugeny
29.08.2018
08:39:14
оно склеивает много лишних колонок
Не совсем понятно, но не оно?
with cte as (
select 1 id, 1 u1, 3 u2 union all
select 2, 2 u1, 2 u2 union all
select 3, 1 u1, 4 u2
)
select case when rn = 1 then u1 else u2 end userID
from (
select u1, u2, ROW_NUMBER() over(partition by u1 order by id) rn
from cte
) t

Kirill
29.08.2018
08:40:24

Eugeny
29.08.2018
08:40:43
missed_images.user_id нету
positions_images.user_id видимо тоже

Kirill
29.08.2018
08:43:36
спасибо.. действительно

Yaroslav
29.08.2018
08:48:03

Kirill
29.08.2018
08:51:18
не уверен на счет count(distinct ..)

Eugeny
29.08.2018
08:51:24

Yaroslav
29.08.2018
08:52:11

Eugeny
29.08.2018
08:52:33

Yaroslav
29.08.2018
08:54:43
не уверен на счет count(distinct ..)
А сколько у Вас может быть записей в missed_images по данному user_id из users (при missed_images"."stage" = '1' )?
Я про это условие:
"missed_images"."user_id" = "users"."id" and "missed_images"."stage" = '1'

Kirill
29.08.2018
08:55:21
не большем чем в каждой из таблиц, которые присутсвуют

Yaroslav
29.08.2018
08:56:21

Eugeny
29.08.2018
09:00:19
select
users.name,
users.email,
users.id as user_id,
(select SUM(CASE WHEN positions_images.is_rejected THEN 1 ELSE 0 END) from positions_images p where p.user_id = u.id) as rejected,
(select COUNT(positions_images.image_id) from positions_images p where p.user_id = u.id) as positions,
(select COUNT(missed_images.image_id) from missed_images p where p.user_id = u.id) as missed
from users u
order by users.email asc;
Hardcore

Google

Kirill
29.08.2018
09:02:41

Eugeny
29.08.2018
09:04:58
@appleboy у тебя в первичном запросе, куча лишних записей до аггрегации доходит, можно написать "NestedLoop" селектом по ID

Yaroslav
29.08.2018
09:05:28
до 1 кк
Тогда сильно похоже, что у Вас запрос неправильный, вот в этой части:
"SUM(CASE WHEN positions_images.is_rejected THEN 1 ELSE 0 END) as rejected,"
К примеру, пусть для данного user_id есть 3 соответсвующих записи в positions_images, и 4 в missed_images (c stage" = '1').
Тогда rejected получится 12. Вы этого хотели?

Kirill
29.08.2018
09:06:43
нет, в этих таблицах максимум может быть одна запись, для одного user_id

Yaroslav
29.08.2018
09:11:32
нет, в этих таблицах максимум может быть одна запись, для одного user_id
А это что значило, в таком случае?!
> до 1 кк
И планировщик с Вами не согласен, кстати:
Hash Right Join (cost=1.50..46.29 rows=1363 width=44) (actual time=0.069..1.169 rows=1376 loops=1)
Seq Scan on missed_images (cost=0.00..26.05 rows=1364 width=8) (actual time=0.025..0.489 rows=1364 loops=1)
Если бы было так, как Вы говорите, там было бы 1364, а не 1376, нет?
(Ну и так далее, выше по плану...)

Kirill
29.08.2018
09:12:08
интересно

Yaroslav
29.08.2018
09:20:18
интересно
Проверили бы Вы запрос, в общем. Можете сравнить результат с тем, что привёл @korhog, например (наверное, это тот результат, который Вам нужен).
(Не считая условия по stage.)

Terminator
29.08.2018
09:35:28
@furkulitsa_k будет жить. Поприветствуем!

nietzschebrod
29.08.2018
09:38:45
ога, мейлру

Kseniya
29.08.2018
09:42:55
привет) сильно нужны админы, чтобы здесь не спамить, направьте на канал с вакансиями что ли?:)

Alexandr
29.08.2018
09:47:30

Andrey
29.08.2018
09:47:44
@furkulitsa_k https://t.me/devops_jobs только внимательно правила прочитайте

Kseniya
29.08.2018
09:49:46

Terminator
29.08.2018
09:57:55
@PeterEgorov будет жить. Поприветствуем!

another
29.08.2018
11:01:33
Привет, не могу на aws базу запустить FATAL: could not map anonymous shared memory: Cannot allocate memory
db.m3.large , 8GB ram , 250GB disk
уже не знаю какие там параметры менять, shared_buffers уже менял

Volodymyr Kostyrko
29.08.2018
12:37:37
Гхм, а версия какая?

Eugeny
29.08.2018
12:51:22

Darafei
29.08.2018
12:52:55
выглядит, как будто кто-то раньше лениво писал на турбо паскале и любит строки длиной 255
стоит попробовать поменять всё на просто text, а id - на uuid

Google

Darafei
29.08.2018
12:54:15
но это только если там нет костылей типа "раньше в это поле мы складывали int, а теперь uuid, потому оно текстовое"

Eugeny
29.08.2018
12:55:51
Я полагаю что причина в миграторе ECM7
хотя не он понимает guid\uuid, видимо все таки турбо паскаль

Yaroslav
29.08.2018
12:58:32
И timestamp without timezone, к тому же.

Bogdan (SirEdvin)
29.08.2018
13:15:50
Хм ... пытаюсь настроить стандартную master-slave репликацию, падает такая странная ошибка, каждый раз вроде накатываю с нуля.
record with incorrect prev-link E987FA71/A00 at 1/27000098
Не подскажите, что это может быть?

S
29.08.2018
13:48:05
а slave вы как создаёте?

Bogdan (SirEdvin)
29.08.2018
14:09:45
Сначала pg_basebackup -h <ip> -D /var/lib/postgresql/data -P -U replica -W --wal-method=stream на чистую папку, потом удаляют recovery.done, создаю такой же recovery.conf и запускаю

S
29.08.2018
14:13:24
а wal как на slave попадают?

Bogdan (SirEdvin)
29.08.2018
14:14:02
Через общую папку

Yaroslav
29.08.2018
14:30:44

Bogdan (SirEdvin)
29.08.2018
14:31:11
Приманученный glusterfs
standby_mode = 'on'
primary_conninfo = 'host={{ postgres_primary_host }} port=5432 user={{ postgres_replica_user }} password={{ postgresql_replica_password }} application_name=slave1'
restore_command = 'cp -f /var/lib/postgresql/archive/%f %p'
trigger_file = '/var/lib/postgresql/trigger/postgresql.trigger'
Как-то так выглядит файл

Yaroslav
29.08.2018
14:34:29

Bogdan (SirEdvin)
29.08.2018
14:34:47
Попытка рековери из archive

Yaroslav
29.08.2018
14:35:35


Bogdan (SirEdvin)
29.08.2018
14:35:53
например, как-то так:
2018-08-29 14:35:24.445 UTC [24] LOG: restored log file "000000010000000100000016" from archive
2018-08-29 14:35:25.197 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098
2018-08-29 14:35:25.197 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098
2018-08-29 14:35:29.211 UTC [24] LOG: restored log file "000000010000000100000016" from archive
2018-08-29 14:35:30.060 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098
2018-08-29 14:35:30.060 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098
2018-08-29 14:35:34.202 UTC [24] LOG: restored log file "000000010000000100000016" from archive
2018-08-29 14:35:35.380 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/16000098
2018-08-29 14:35:35.381 UTC [24] LOG: record with incorrect prev-link 7000000/5 at 1/1600009
Совсем полный лог: https://pastebin.com/ifwvM43z