РА
за идею спасибо
Size: a a a
2020 August 22
YS
у меня недостаточно знаний чтобы про OOM killer ответить
А Вы логи OS посмотрите. В любом случае, этот сигнал кто-то почему-то послал, и это был не PostgreSQL.
L
Yaroslav Schekin
Этот вопрос можно задать и наоборот. ;)
И да, в "letter varchar(1)" можно вставить как пустую строку, так и цифру — это точно правильно?
И да, в "letter varchar(1)" можно вставить как пустую строку, так и цифру — это точно правильно?
Пустую строку - скорее пробел или какой-то не алфавитный символ, но text от этого тоже не спасёт
YS
Пустую строку - скорее пробел или какой-то не алфавитный символ, но text от этого тоже не спасёт
От этого спасёт CHECK.
L
Там 150 млн строк надо вставить, я даже pk удалять на время операции думаю, check точно не хочу делать, лучше в бизнес логике накручу проверок)
YS
Там 150 млн строк надо вставить, я даже pk удалять на время операции думаю, check точно не хочу делать, лучше в бизнес логике накручу проверок)
Это крохоборство, IMHO (тогда уж и (1) уберите из varchar, и вообще замените его на просто text — эта проверка же тоже какие-то микросекунды занимает).
Наверное, эти "бизнес" данные настолько "важны", что ошибки в них не стоят лишних микросекунд, если что. ;)
Наверное, эти "бизнес" данные настолько "важны", что ошибки в них не стоят лишних микросекунд, если что. ;)
L
Данные как раз не важны, но скорость вставки критична))
L
Т.е. это просто данные из одной системы переливаются в другую, для удобной работы, поэтому всегда они есть в виде выгрузки
L
Спасибо за совет, уберу тогда)
L
+------------------------------------------------------------------------------------------------------------+
|QUERY PLAN |
+------------------------------------------------------------------------------------------------------------+
|Update on t1 d (cost=45.09..67.30 rows=3 width=75) (actual time=0.009..0.009 rows=0 loops=1) |
| -> Hash Join (cost=45.09..67.30 rows=3 width=75) (actual time=0.008..0.008 rows=0 loops=1) |
| Hash Cond: ((d.domain)::text = (x.domain)::text) |
| -> Seq Scan on t1 d (cost=0.00..19.75 rows=650 width=23) (actual time=0.008..0.008 rows=0 loops=1)|
| Filter: ((tld_id = 1) AND ((letter)::text = '0'::text)) |
| -> Hash (cost=45.05..45.05 rows=3 width=23) (never executed) |
| -> Hash Right Join (cost=26.25..45.05 rows=3 width=23) (never executed) |
| Hash Cond: ((y.domain)::text = (x.domain)::text) |
| Filter: (y.* IS NOT DISTINCT FROM NULL) |
| -> Seq Scan on t2 y (cost=0.00..13.70 rows=370 width=378) (never executed) |
| -> Hash (cost=18.12..18.12 rows=650 width=17) (never executed) |
| -> Seq Scan on t1 x (cost=0.00..18.12 rows=650 width=17) (never executed) |
| Filter: ((deleted_at IS NULL) AND (tld_id = 1)) |
|Settings: search_path = 'public' |
|Planning Time: 1.184 ms |
|Execution Time: 4.172 ms |
+------------------------------------------------------------------------------------------------------------+L
запрос:
EXPLAIN (ANALYZE, BUFFERS, SETTINGS)
UPDATE
t1 D
SET
name_servers = '{}',
updated_at = null,
deleted_at = '2020-08-22'
FROM
t1 X
LEFT JOIN
t2 Y
USING (domain)
WHERE
D.tld_id = 1 AND
D.letter = '0' AND
D.domain = X.domain AND
D.tld_id = X.tld_id AND
X.deleted_at is null AND
Y IS NOT DISTINCT FROM NULL; -- "антиджойн"L
нужно ли добавлять индексы, как думаете?
L
или может быть что бы вы поменяли в этом запросе, чтоб он был оптимальнее?
AI
2flower _
для этого вполне есть check
ну поидее дб могла бы использовать эту инфу чтобы эффективнее хранить внутри
2_
ну поидее дб могла бы использовать эту инфу чтобы эффективнее хранить внутри
а представьте по идее, что в большой таблице вам надо сделать не (70), а (50), или (90),
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
AI
2flower _
а представьте по идее, что в большой таблице вам надо сделать не (70), а (50), или (90),
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
ну это тоже самое что переделать поле из цифрового в строковое. Тоже не простой процесс. Для того и подбираются правильные структуры данных, верно?
AI
ну я не думаю что постгрес под капотом как то варчар оптимизирует, но мог бы.
AI
2flower _
а представьте по идее, что в большой таблице вам надо сделать не (70), а (50), или (90),
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
с check это сделать ГОРАЗДО быстрее и удобнее.
Я сам долгое время думал как вы, но когда внимательно обдумал, что говорят старшие товарищи, признал их точку зрения.
да не я то согласен что на практике проще текстом хранить
2_
ну это тоже самое что переделать поле из цифрового в строковое. Тоже не простой процесс. Для того и подбираются правильные структуры данных, верно?
вы не поняли, я говорю об изменении размерности поля varchar(70) на varchar(50) или varchar(90) если у вас там 200кк записей например.
AI
2flower _
вы не поняли, я говорю об изменении размерности поля varchar(70) на varchar(50) или varchar(90) если у вас там 200кк записей например.
да я то понял