можно будет вообще не рефлексировать

прикольное преимущество у БД делать вещи правильно

еще "PostgreSQL always does things correctly!"

Читая это где-то тут плачет один несчастный человек, ага.

Постгрес более требователен к квалификации "пользователей" - то есть разработчиков и администраторов, зато и более предсказуем в плане надёжности - just works, that's it.

да ничо он не требователен. нет в нем ничо такого сложного. stackoverflow все стерпит

Особенно correctly, когда экземпляр сынициализирован без чексумм.

Постгрес более требователен к квалификации "пользователей" - то есть разработчиков и администраторов, зато и более предсказуем в плане надёжности - just works, that's it.

Администрировать мыскль проще?! Это серьёзно?! Годный заход, да...

Администрировать мыскль проще?! Это серьёзно?! Годный заход, да...

Это моё личное мнение, и я никоим образом его не навязываю. Вполне допускаю, что это самое мнение окружающие могут считать ошибочным - у меня не подгорит.

Особенно correctly, когда экземпляр сынициализирован без чексумм.

Я с некоторых пор всегда инициализирую с ними. И да, лучше бы это было по умолчанию.

с мыскля на постгрес и говорить о выгоде?! о_О

можно еще производительность обсудить )

конференция близко, все разминаются видимо :)

еще "PostgreSQL always does things correctly!"

А это откуда (просто любопытно)?

подскажите, а есть группировка, которая позводит собрать значения из столбца в массив?

array_agg

сеньк, сам не нашёл в доке :(

Коллеги, подскажите, пожалуйста, есть таблица с двумя колонками № и Boolean. В номере есть дубликаты. Мне нужно убрать дубликаты, приоритет Boolean = true. Если вводных не хватает , напишите.

насколько велика и насколько можно лочить?

create table new_table as (select distinct on (num) * from ttt order by boolfield desc nulls last);

и дропнуть и переименовать

Коллеги, подскажите, пожалуйста, есть таблица с двумя колонками № и Boolean. В номере есть дубликаты. Мне нужно убрать дубликаты, приоритет Boolean = true. Если вводных не хватает , напишите.

Удалить, в смысле? Или только выбрать?

и дропнуть и переименовать

Осторожно: это можно делать, если параллельно с ней никто не работает (ну это если Вам корректность результатов запросов к ней вообще важна).

Удалить, в смысле? Или только выбрать?

Выбрать.

Выбрать.

Если дубликатов на один номер немного, то DISTINCT ON, примерно как выше показали.

Я вижу, что здесь на один proc_number две записи. Если это в среднем так, опять-таки, см. выше.

подскажите, плиз, в столбце находится jsonb массив объектов key:value, т.е. [{key1":"value1"},{{key2":"value1"}]. как можно их агрегировать в один массив уникальных объектов? jsonb_agg делает массив массивов

подскажите, плиз, в столбце находится jsonb массив объектов key:value, т.е. [{key1":"value1"},{{key2":"value1"}]. как можно их агрегировать в один массив уникальных объектов? jsonb_agg делает массив массивов

Так что должно получиться-то? Array? JSONb array? И какой результат в этом примере?

[{key1":"value1"},{key2":"value1"}] + [{key1":"value1"},{key3":"value3"}] результат должен быть [{key1":"value1"},{key2":"value1"},{key3":"value3"}] не важно jsonb или array

Что лучше использовать как PK, обычное инкрементное поле или uuid?

Что лучше использовать как PK, обычное инкрементное поле или uuid?

абсолютно точного ответа не существует. мне uuid не нравится, но где-то инкремент не вариант вообще

три "не" в одном ответе. это личный рекорд!)

[{key1":"value1"},{key2":"value1"}] + [{key1":"value1"},{key3":"value3"}] результат должен быть [{key1":"value1"},{key2":"value1"},{key3":"value3"}] не важно jsonb или array

— То есть что-то типа такого? WITH a(j) AS ( VALUES ('[{"key1":"value1"},{"key2":"value1"}]'::jsonb), ('[{"key1":"value1"},{"key3":"value3"}]') ), grouped AS ( SELECT kv.key, kv.value FROM a CROSS JOIN jsonb_array_elements(a.j) AS v(v) CROSS JOIN jsonb_each(v.v) AS kv(key, value) GROUP BY kv.key, kv.value ) SELECT jsonb_agg(jsonb_build_object(key, value)) FROM grouped

Что лучше использовать как PK, обычное инкрементное поле или uuid?

По-моему, обычное инкрементное поле в большинстве случаев. UUID можно добавить и потом, если он понадобится для обмена с другими системами или чего-то подобного.

Правдиво ли моё утверждение что uuid не особо хорош из-за чуть более медленная вставка в индекс так как вставка будет проходить не в конец дерева а в середину из-за этого будет ребаланс?

Хотя и в конец тоже ребаланс

@az09_mgn, Yaroslav, понял, спасибо за ответы

Правдиво ли моё утверждение что uuid не особо хорош из-за чуть более медленная вставка в индекс так как вставка будет проходить не в конец дерева а в середину из-за этого будет ребаланс?

Конечно правдиво. И главное тут не ребаланс, а то, что serial всегда вставляется в последнюю страницу индекса, а вот UUID —- в случайную. Enters the cache. :(

Конечно правдиво. И главное тут не ребаланс, а то, что serial всегда вставляется в последнюю страницу индекса, а вот UUID —- в случайную. Enters the cache. :(

Спасибо большое

Что лучше использовать как PK, обычное инкрементное поле или uuid?

если хочется и последовательности и секретности или отсутствия координации, то ulid можно взять

@az09_mgn, Yaroslav, понял, спасибо за ответы

Рассчитывайте, что по совокупности факторов UUIID может быть медленее раз в 40 (навскидку, но где-то я эту цифру видел).

Это хреновая секретность.

— То есть что-то типа такого? WITH a(j) AS ( VALUES ('[{"key1":"value1"},{"key2":"value1"}]'::jsonb), ('[{"key1":"value1"},{"key3":"value3"}]') ), grouped AS ( SELECT kv.key, kv.value FROM a CROSS JOIN jsonb_array_elements(a.j) AS v(v) CROSS JOIN jsonb_each(v.v) AS kv(key, value) GROUP BY kv.key, kv.value ) SELECT jsonb_agg(jsonb_build_object(key, value)) FROM grouped

спасибо. пока развернул значения при помощи jsonb_array_elements, а затем уже использовал jsonb_agg. Жаль сразу нельзя, select from select городить пришлось

Правдиво ли моё утверждение что uuid не особо хорош из-за чуть более медленная вставка в индекс так как вставка будет проходить не в конец дерева а в середину из-за этого будет ребаланс?

https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/ Есть ещё вот такая проблема

о спасибо большое !

https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/ Есть ещё вот такая проблема

Вообще это в духе пг написать что такой присяд по перформансу будет ойойой, но вы параметр этот не троньте тк пг будет немного поломан если чо, но мы его для удобства уничтожения вашей БД вынесли в guc. А потом появляются админы в слезах , такие что fsync и этот fullpage выключают тк пг с нагрузкой не справился изза тогоже write amplification, но ручки покрутить дают и статьи провокационные пишут. А то что не дают поменять прям в коде definами намазывают иногда ,обосновывая принципом бабка надвое сказала и нефиг лезть в наш мир высоких нагрузок, созданных pgbench на ноутбуке, хотя вреда с этих definов в виде guc гораздо меньше будет, а толку в тюнинге может и поболее будет.

Вообще это в духе пг написать что такой присяд по перформансу будет ойойой, но вы параметр этот не троньте тк пг будет немного поломан если чо, но мы его для удобства уничтожения вашей БД вынесли в guc. А потом появляются админы в слезах , такие что fsync и этот fullpage выключают тк пг с нагрузкой не справился изза тогоже write amplification, но ручки покрутить дают и статьи провокационные пишут. А то что не дают поменять прям в коде definами намазывают иногда ,обосновывая принципом бабка надвое сказала и нефиг лезть в наш мир высоких нагрузок, созданных pgbench на ноутбуке, хотя вреда с этих definов в виде guc гораздо меньше будет, а толку в тюнинге может и поболее будет.

Дело в том, что любая СУБД, которая использует WAL (т.е. чуть менее чем все существующие) должна исполнять такие "танцы" (если только FS не танцует их сама), иначе она не durable. Так что... какие претензии-то?

Дело в том, что любая СУБД, которая использует WAL (т.е. чуть менее чем все существующие) должна исполнять такие "танцы" (если только FS не танцует их сама), иначе она не durable. Так что... какие претензии-то?

убрать эти параметры из guc и сделать их define . а хочеться если перформанса без гарантий - тогда tmpfs

А если я быстро хочу сделать начальную загрузку данных, а если что не так —- снесу кластер и повторю ещё раз? Почему Вы у меня хотите эту возможность отобрать?

а вот такое что ой такой классный параметр но пг без него консервная банка - это лукавство

а вот такое что ой такой классный параметр но пг без него консервная банка - это лукавство

Где Вы это вычитали? Кто его рекомендует на prod-е включать "просто так"? Кстати, по идее, есть FS (ZFS?), на которых он не нужен.

А если я быстро хочу сделать начальную загрузку данных, а если что не так —- снесу кластер и повторю ещё раз? Почему Вы у меня хотите эту возможность отобрать?

это не возможность а лишний повод показать что пг не так хорош по перформансу когда он таки начинает ACID делать

это не возможность а лишний повод показать что пг не так хорош по перформансу когда он таки начинает ACID делать

Ещё раз: _любая_ база должна это делать, иначе она не ACID. Так что все здесь в равных условиях, нет?

Где Вы это вычитали? Кто его рекомендует на prod-е включать "просто так"? Кстати, по идее, есть FS (ZFS?), на которых он не нужен.

Включать или выключать?

Так же вот даже из этой статьи изречение- 8kB and 4kB pages - (which requires compiling a custom package). but reduction from ~140GB to ~90GB is still quite significant.

Выключать (очепятался).

Иии? Где та ручка насчет поменять размер блока?

Но есть ручка - eatmydata

Логика не очень на мой взгляд

Но есть ручка - eatmydata

Это не "eatmydata". Я Вам уже назвал 2 причины её существования.

Иии? Где та ручка насчет поменять размер блока?

Нету. :(

Сейчас вот тесты некоторые делаю - там вот например запись WAL свыше гигабайта в секунду, была бы ручка было бы меньше

Размер вал файла тоже уже коммуна обсуждает давно

Много есть чего. Я понимаю что выключение этих параметров позволит быстрее загрузит данные, но: Но их в основном начинают использовать не для массовой загрузки а потому что сервер быстрее начинает работать.

Вот это высказывание тоже интересное- But even if it’s still an issue, data checksums may be sufficient protection (it won’t fix the issue, but will at least let you know there’s a broken page).

Да вы знаете что страница битая и при этом не имеете возможность эту страницу из бекапа или с реплики восстановить , переключаетесь на реплику, заливаете старый мастер и пока он заливается пальцы крестиком

Сейчас вот тесты некоторые делаю - там вот например запись WAL свыше гигабайта в секунду, была бы ручка было бы меньше

Кто Вам мешает делать свои сборки (пакеты)? У этого, кстати, есть и другие преимущества (вроде возможности тут же применить bugfix для именно Вашей проблемы, до release-а).

Много есть чего. Я понимаю что выключение этих параметров позволит быстрее загрузит данные, но: Но их в основном начинают использовать не для массовой загрузки а потому что сервер быстрее начинает работать.

Ну кто-то и с fsync=off наперевес бегает. ;)

Ну кто-то и с fsync=off наперевес бегает. ;)

Конечно, основной посыл быстрее.

Вот это высказывание тоже интересное- But even if it’s still an issue, data checksums may be sufficient protection (it won’t fix the issue, but will at least let you know there’s a broken page).

Это да, весело.

Кто Вам мешает делать свои сборки (пакеты)? У этого, кстати, есть и другие преимущества (вроде возможности тут же применить bugfix для именно Вашей проблемы, до release-а).

Это не мешает делать тому, кто знает и понимает что и где делать, для простых пользователей ПГ это не так доступно во первых, а во вторых за использование кастомных пакетов можно и получить по шапке случись чего

Это не мешает делать тому, кто знает и понимает что и где делать, для простых пользователей ПГ это не так доступно во первых, а во вторых за использование кастомных пакетов можно и получить по шапке случись чего

Первое —- да, второе —- а можно получить и за неиспользование. ;)

Вот эта мысль тоже интересная - So it’s important to tune checkpoints not to happen too often. При этом про портянку из wal файлов уже никакими барьерами не контролируемую при этом ни слова.

Но посыл-то правильный, а статья совсем не об этом. ;)

https://techno.2gis.ru/event/postgresqlday Брюс Момжан в Новосибирске, 12 февраля

В чем проблема, кто подскажет?

Пытаетесь много раз выбрать count(*) из таблицы J

http://www.letmegooglethat.com/?q=ORA-00942

а нужно в духе https://docs.oracle.com/cloud/latest/db112/LNPLS/dynamic.htm#LNPLS01108

Я уже плохо помню plsql, но кажется вам надо использовать динамический sql.

И потом неясно, КУДА вы выбираете.

"j" здесь - не таблица, из нее нельзя сделать select. j в цикле for - это строка (1 запись) таблицы (точнее, dictionary, но не важно) user_tables со всеми соответствующими полями (j.table_name, j.iot_name). Если задача посчитать там записи (select count(*), то цикл вообще не нужен, цикл нужен для работы с полями внутри каждой отобранной записи. Какая вообще задача-то?

про j.iot_name я загнул (выбирается только table_name), но сути, опять же, не меняет

"j" здесь - не таблица, из нее нельзя сделать select. j в цикле for - это строка (1 запись) таблицы (точнее, dictionary, но не важно) user_tables со всеми соответствующими полями (j.table_name, j.iot_name). Если задача посчитать там записи (select count(*), то цикл вообще не нужен, цикл нужен для работы с полями внутри каждой отобранной записи. Какая вообще задача-то?

А у нас здесь уже канал про Oracle? ;)

Что ж теперь, и на вопрос не отвечать?

Тем более, что логика plsql и plpgsql во многом схожа

Что ж теперь, и на вопрос не отвечать?

Можно перейти в соответсвующий канал, например. Иначе те, кто читает дискуссию не сначала, могут запутаться.

Можно перейти в соответсвующий канал, например. Иначе те, кто читает дискуссию не сначала, могут запутаться.

Разумно, на всякий случай повторю ссылочку - https://t.me/oracle_ru

Но вообще, там вяленько, народу мало

вяленько - в https://t.me/mssql_ru ?

Всем доброго времени суток! Не мог бы кто-нибудь подсказать новичку по апдейту множества ключей jsob в одном запросе: к примеру есть запись - id | payload | status 3 | {"DialogID": 8, "TotalDuration": 3} |4 Я хочу сделать update сразу для "DialogID" и для "TotalDuration" - возможно ли это? Нужно использовать jsonb_set или что-то другое? Заранее спасибо за ответ!