Size: a a a

pgsql – PostgreSQL

2021 January 26

am

a m in pgsql – PostgreSQL
Владислав
День добрый, подскажите,  насколько время обновления с 9.4 до 13 зависит от объема данных в базе? Мне казалось что там используются hard links и время обновления не должно сильно зависеть от объема данных
У pg_upgrade есть --link, да. Только что толку, если все равно прочитать все надо.
источник

DS

Daniella Starchenko in pgsql – PostgreSQL
хорошо. Еще вопрос: как узнать какие очереди задач существуют у меня в постгресе? какой запрос для этого есть?
источник

DS

Daniella Starchenko in pgsql – PostgreSQL
и идут ли разные бекенды в разные очереди выполнения? Можно ли как то с помощью распределения выполения очередей распределить нагрузку?
источник

VY

Victor Yegorov in pgsql – PostgreSQL
a m
У pg_upgrade есть --link, да. Только что толку, если все равно прочитать все надо.
хм, что прочитать? только системный каталог, всё остальное линкуется. у меня еженедльные тесты на 10TB базе с 2-мя табличными областями — 31 минута в среднем на апгрейд со сбором полной статы.
источник

am

a m in pgsql – PostgreSQL
Victor Yegorov
хм, что прочитать? только системный каталог, всё остальное линкуется. у меня еженедльные тесты на 10TB базе с 2-мя табличными областями — 31 минута в среднем на апгрейд со сбором полной статы.
Интересно. Тогда я вообще плохо понимаю, зачем pg_upgrade нужен.
источник

VY

Victor Yegorov in pgsql – PostgreSQL
a m
Интересно. Тогда я вообще плохо понимаю, зачем pg_upgrade нужен.
в смысле? это он и делает всё. без него имеем либо pg_dump+pg_restore с непонятным, но где-то в районе суток даунтаймом. либо через логическую репликацию, с плясками по переносу схему и синхронизации всего, кроме таблиц.
источник

am

a m in pgsql – PostgreSQL
Victor Yegorov
в смысле? это он и делает всё. без него имеем либо pg_dump+pg_restore с непонятным, но где-то в районе суток даунтаймом. либо через логическую репликацию, с плясками по переносу схему и синхронизации всего, кроме таблиц.
А что он такого делает, чего нельзя воткнуть в код постгреса, чтобы он, обнаружив старую версию под собой, молча жевал свой системный каталог? Recovery же мы тоже не вручную запускаем, и никто не умирает от этого.
источник

K

Kamoliddin in pgsql – PostgreSQL
Добрый вечер. Вопрос не по теме чата но всё же. https://postgrespro.ru/education

Есть ли подобные курсы только по oracle ?
источник

VY

Victor Yegorov in pgsql – PostgreSQL
a m
А что он такого делает, чего нельзя воткнуть в код постгреса, чтобы он, обнаружив старую версию под собой, молча жевал свой системный каталог? Recovery же мы тоже не вручную запускаем, и никто не умирает от этого.
pg_upgrade — системная утилита, которая:
- делает проверку совместимости инсталляций
- переносит системный каталог
- линкует файлы
- правит контольные файлы.
в код постгреса это не втыкают чтобы не сложнять его, т.к. пришлось бы слишком много ветвлений для разных версий иметь.
т.к. перезапуск всё равно нужен, делаем всю работу через утилиту
источник

VY

Victor Yegorov in pgsql – PostgreSQL
Kamoliddin
Добрый вечер. Вопрос не по теме чата но всё же. https://postgrespro.ru/education

Есть ли подобные курсы только по oracle ?
ORACLE Academy или ищите подготовку на ORACLE Certified Professional
источник

am

a m in pgsql – PostgreSQL
Victor Yegorov
pg_upgrade — системная утилита, которая:
- делает проверку совместимости инсталляций
- переносит системный каталог
- линкует файлы
- правит контольные файлы.
в код постгреса это не втыкают чтобы не сложнять его, т.к. пришлось бы слишком много ветвлений для разных версий иметь.
т.к. перезапуск всё равно нужен, делаем всю работу через утилиту
Ну хорошо. Не в код. Но пусть он этот pg_upgrade сам вызывает и сам себя перезапускает. Какого черта я, средняя скриптомакака, которая ничего сложнее инстанса за $10 на AWS в жизни не видела, должна пользоваться отдельной утилитой, у которой 10 опций командной строки, позволяющих по-разному отстрелить себе ноги?
источник

D

Daniel in pgsql – PostgreSQL
a m
Это надо код читать, а мне лень.
Сделал очень примитивный тест (эмуляция приложения). У меня выходит, что SELECT+UPDATE - это дольше, чем INSERT ON CONFLICT
источник

R

Radist in pgsql – PostgreSQL
a m
А что он такого делает, чего нельзя воткнуть в код постгреса, чтобы он, обнаружив старую версию под собой, молча жевал свой системный каталог? Recovery же мы тоже не вручную запускаем, и никто не умирает от этого.
Ради того, что происходит раз в год, делать нетривиальный анализ каждый раз при... старте/первом обращении к таблице? А если что-то пойдёт не так? Апгрейд - всё-таки планируемая операция, а тут нежданчик може прилететь после каждого рестарта СУБД. Например, флипнулся бит где-нибудь в заголовке таблицы - просто она не будет читаться. А если встроить апгрейд, то можно вообще попортить все данные из-за ложного детекта.
источник

am

a m in pgsql – PostgreSQL
Daniel
Сделал очень примитивный тест (эмуляция приложения). У меня выходит, что SELECT+UPDATE - это дольше, чем INSERT ON CONFLICT
Круто. А у вас точно perpared statements?
источник

am

a m in pgsql – PostgreSQL
Daniel
Сделал очень примитивный тест (эмуляция приложения). У меня выходит, что SELECT+UPDATE - это дольше, чем INSERT ON CONFLICT
(также весьма вероятен вариант, что ваш язык программирования вместе с библиотеками тормозит больше, чем упсерт)
источник

D

Daniel in pgsql – PostgreSQL
a m
Круто. А у вас точно perpared statements?
CREATE TABLE messages_test (
id bigint PRIMARY key,
message text,
ts timestamptz
);

INSERT INTO messages_test SELECT a.id, a.id::text, now() FROM generate_series(1,5000000) AS a(id);

ANALYZE messages_test;

DO $$
DECLARE
v_i int;
v_exists bool;
BEGIN
FOR v_i IN 4000000..6000000 LOOP
 v_exists := 1 FROM messages_test WHERE id = v_i;
 IF v_exists THEN
  UPDATE messages_test SET ts = now() WHERE id = v_i;
 ELSE
  INSERT INTO messages_test(id, message, ts) VALUES (v_i, v_i::text, now());
 END IF;
END LOOP;
END $$ LANGUAGE plpgsql;
-- 31.377 s

SELECT max(id) FROM messages_test; -- 6000000
SELECT min(ts), max(ts) FROM messages_test; -- 2021-01-26 18:27:47 2021-01-26 18:28:05

-- 24.783 s
DO $$
DECLARE
v_i int;
BEGIN
FOR v_i IN 4000000..6000000 LOOP    
 INSERT INTO messages_test(id, message, ts) VALUES (v_i, v_i::text, now())
 ON CONFLICT (id) DO UPDATE SET ts = now();
END LOOP;
END $$ LANGUAGE plpgsql;

SELECT max(id) FROM messages_test; -- 6000000
SELECT min(ts), max(ts) FROM messages_test; -- 2021-01-26 18:29:59 2021-01-26 18:32:10
источник

am

a m in pgsql – PostgreSQL
Daniel
CREATE TABLE messages_test (
id bigint PRIMARY key,
message text,
ts timestamptz
);

INSERT INTO messages_test SELECT a.id, a.id::text, now() FROM generate_series(1,5000000) AS a(id);

ANALYZE messages_test;

DO $$
DECLARE
v_i int;
v_exists bool;
BEGIN
FOR v_i IN 4000000..6000000 LOOP
 v_exists := 1 FROM messages_test WHERE id = v_i;
 IF v_exists THEN
  UPDATE messages_test SET ts = now() WHERE id = v_i;
 ELSE
  INSERT INTO messages_test(id, message, ts) VALUES (v_i, v_i::text, now());
 END IF;
END LOOP;
END $$ LANGUAGE plpgsql;
-- 31.377 s

SELECT max(id) FROM messages_test; -- 6000000
SELECT min(ts), max(ts) FROM messages_test; -- 2021-01-26 18:27:47 2021-01-26 18:28:05

-- 24.783 s
DO $$
DECLARE
v_i int;
BEGIN
FOR v_i IN 4000000..6000000 LOOP    
 INSERT INTO messages_test(id, message, ts) VALUES (v_i, v_i::text, now())
 ON CONFLICT (id) DO UPDATE SET ts = now();
END LOOP;
END $$ LANGUAGE plpgsql;

SELECT max(id) FROM messages_test; -- 6000000
SELECT min(ts), max(ts) FROM messages_test; -- 2021-01-26 18:29:59 2021-01-26 18:32:10
Для пущей верности запустите в несколько потоков.
источник

D

Daniel in pgsql – PostgreSQL
ну то есть, я могу поверить, что INSERT ON CONFLICT будет не медленнее, чем SELECT + UPDATE, но за счёт чего он может быть медленнее?
источник

D

Daniel in pgsql – PostgreSQL
a m
Для пущей верности запустите в несколько потоков.
думал про это, но вроде бы @IlyaKaznacheev говорил об одном потоке?
источник

VY

Victor Yegorov in pgsql – PostgreSQL
SELECT + UPDATE не избавляет от коллизий же. запустите интенсивный тест в 4+ параллельных сессии и понаблюдайте.
https://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/
источник