forum.opennet.ru - "Релиз СУБД PostgreSQL 13" (132)

"Релиз СУБД PostgreSQL 13"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Релиз СУБД PostgreSQL 13"	+/–
Сообщение от opennews (?), 24-Сен-20, 19:05
После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 13. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2025 года... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53774
Ответить \| Правка \| Cообщить модератору

Оглавление

Замечательная БД Лучшая в мире, имхо , DEF (?), 19:05 , 24-Сен-20, (1) +26

Постгря объективно лучшая, так что имхо тут лишнее, Аноним (2), 19:08 , 24-Сен-20, (2) +5

Ну, это вы за своё имхо так говорите , Аноним (7), 19:19 , 24-Сен-20, (7) +6
Постгрес, там 171 с 187 в конце , Аноним (12), 19:41 , 24-Сен-20, (12) –7

171 с 187 не в конце, а в начале SQL, Аноним (18), 19:57 , 24-Сен-20, (18) +7

А в слове прогресс тоже в начале Или это такой троллинг Вообще надо секту п, Аноним (21), 20:21 , 24-Сен-20, (21) –1

Если ты заметил, в прогресс нет суффикса SQL , Аноним (18), 21:28 , 24-Сен-20, (26) +1

Нет, https ru wikipedia org wiki PostgreSQLСлово postgres образовано от Post , Аноним (12), 20:46 , 24-Сен-20, (22) +13
https www postgresql org docs current history html AEN187Berkley POSTGRES с 1, Аноним (23), 20:57 , 24-Сен-20, (23) +2

Ага, настолько классная что Uber с неё свинтил на MySQL свой напилиник по поня, mr.Clin (?), 22:23 , 24-Сен-20, (27) –4

Свой напильник можно было и в постгресе сделать, это чисто политическое решение,, Аноним (42), 04:20 , 25-Сен-20, (42) +1
Если бы Uber провёл то самое исследование производительности на этапе проектиров, Аноним (48), 07:59 , 25-Сен-20, (48) +9

Там не только проблема со вторичными индексами была, с VACUUM проблема более-мен, mr.Clin (?), 13:12 , 25-Сен-20, (61)

Проблема там была только с мозгами и откатами Устроить миграцию MySQL - PostreS, zzz (??), 04:45 , 26-Сен-20, (77)
Про вакуум в постгресе знают вроде вообще все, даже те, кто запросов сложнее sel, Аноним (48), 05:01 , 26-Сен-20, (79)

Как может быть лучше субд у которой это говновакуум вообще существует А дебильны, n242name (?), 06:21 , 26-Сен-20, (80) –4

В postgres регистронезависимые имена , Аноним (42), 00:21 , 27-Сен-20, (109) –1

но регистр он не запоминает в отличии от MySQLможно смело забыть про PascalCas, n242name (?), 01:41 , 27-Сен-20, (111) –1

Куда там Oracle, Ms SQL Server и IBM DB2, да Это просто мальчики для биться по , Страшный Аноним (?), 23:33 , 24-Сен-20, (32) +1

Правильно писать Postgres, Аноним (42), 04:18 , 25-Сен-20, (41)

Лучший ответ на заданный вопрос , Pers (??), 07:19 , 25-Сен-20, (46) +13
Да там и с русским проблема, не то что с названиями , Аноним (57), 12:15 , 25-Сен-20, (57) –1
Правильно - рисовать слоника , InuYasha (??), 17:01 , 25-Сен-20, (69) –1

А при чём здесь РНР , Аноним (57), 20:47 , 25-Сен-20, (76)

Аноны, вы вконец ослепли https www postgresql org media img about press eleph, InuYasha (??), 12:29 , 28-Сен-20, (126)

Чтоб продавать постгре вместо оракла Но на больших БД - поддержка постгри дороже, 1 (??), 12:15 , 25-Сен-20, (58) –2

Очевидно что вы не разбираетесь в теме раз даже не знаете как база правильно наз, Аноним (12), 14:46 , 25-Сен-20, (67)

За тем, что Postgres отжал у Oracle рынок, а это добивает последних Я еще в 2011, Виталий (??), 09:20 , 29-Сен-20, (128)
Чем легче перенести код с PL SQL на PL pgsql - тем больше пользователей это сдел, ptr128 (?), 11:49 , 30-Сен-20, (131)

Кстати, как там в Postgre с партиционированием, завезли полноценное или еще на 5, Страшный Аноним (?), 23:38 , 24-Сен-20, (33) –3

На ручном приводе я ещё в 2003 партицирование делал пользуясь наследованием, кот, funny.falcon (?), 03:48 , 25-Сен-20, (40) +1
В postgres, да, завезли , Аноним (42), 04:21 , 25-Сен-20, (43)
Давно уже есть С десятой версии вроде , Аноним (48), 08:02 , 25-Сен-20, (49)
Это только в энтерпрайзной версии, которая многие миллионы стоит, которую только, Аноним (53), 09:54 , 25-Сен-20, (53)

Лучшая в мире БД для лучшего в мире юзкейса, лолшто (?), 17:49 , 25-Сен-20, (71) +1
JSON там считай что нет Соответственно, лучшая средневековая СУБД В Монге, кста, лютый жабби__ (?), 12:11 , 26-Сен-20, (86) –1

В монге так реализовали транзакции, что и оставшиеся 2 не выйдет использовать , Cykooz (ok), 23:09 , 26-Сен-20, (106)

Я вообще ХЗ как может быть невасян СУБД без реплик учитывая время разворачива, лютый жабби__ (?), 11:44 , 27-Сен-20, (113)

Если придираться к словам, то репликация - это не то же самое что бекап, и не за, Cykooz (ok), 13:24 , 27-Сен-20, (114)

- реплики редко нужны -нет, реплики нужны всегда, т к время разворачивания бэка, лютый жабби__ (?), 11:02 , 28-Сен-20, (121)

В чём хрень Если у тебя приложение или хакеры испоганит данные в базе, то эти, Cykooz (ok), 12:06 , 28-Сен-20, (124)

Ждём появления магазина дополнений, которые можно ставить в один клик А то несо, YetAnotherOnanym (ok), 19:13 , 24-Сен-20, (3) –5

Куда же без монетизации и монетизации на монетизацию , Рева RarogCmex Денис (?), 19:13 , 24-Сен-20, (5)
https pgxn org about , Аноним (12), 19:43 , 24-Сен-20, (13) +2

О, круто А дыры, дыры-то есть А то ж дополнение без дыр - это какое-то неполно, YetAnotherOnanym (ok), 01:07 , 25-Сен-20, (37)

Как напишешь 8212 так и будет , Аноним (42), 04:22 , 25-Сен-20, (44)

Неплохая бд под свои цели тяжелые приложения под реляционрую базу данных Поня, Рева RarogCmex Денис (?), 19:13 , 24-Сен-20, (4) –1

sqlite на порядки эффективнее - это интересная идея Удобнее и компактнее - да, , Аноним (6), 19:15 , 24-Сен-20, (6) +5

В РЯДЕ СЛУЧАЕВ эффективнеевнимательнее надо с областью определения утверждений, Аноним (8), 19:31 , 24-Сен-20, (8) +4

даже не В РЯДЕ СЛУЧАЕВ, а в В НЕКОТОРЫХ СЛУЧАЯХ , Sw00p aka Jerom (?), 19:43 , 24-Сен-20, (14)

В исходном утверждении стоит именно в ряде случаев Не понимаю, что за мода выкид, Аноним (8), 19:49 , 24-Сен-20, (16) +3

И ну и как тут не ответить Мой комент был всего лишь поправкой, и с исходным ко, Sw00p aka Jerom (?), 00:49 , 25-Сен-20, (34) –1

Для записной книжки в телефоне - эффективнее , Аноним (9), 19:31 , 24-Сен-20, (9) +6

Таких инсталляций на порядки больше, чем корпоративных БД Так что правильно гов, x3who (?), 11:31 , 26-Сен-20, (85)

Кстати, не припомню ни одного случая, когда монга была бы именно эффективнее Пр, Аноним (9), 19:34 , 24-Сен-20, (10)

В основном в разработке чужого бюджета, Аноним (15), 19:43 , 24-Сен-20, (15) +6
Это только потому, видимо, что вам _пока_ не требовалось от СУБД умение работать, jOKer (ok), 01:31 , 25-Сен-20, (39)

Монга первая в мире СУБД с partition tolerance, ога Мы такое кастомной MySQL pr, Аноним (48), 07:38 , 25-Сен-20, (47) +4

gt оверквотинг удален А можно меньше слюней, пены и соплей, и побольше того, ч, jOKer (ok), 18:13 , 25-Сен-20, (72) –1

О, вот и фанбои подтянулись https www postgresql org docs 13 functions-json ht, Аноним (48), 04:53 , 26-Сен-20, (78) +1

Похоже, что читать внимательно стоит как раз вам Там ни пол-слова нет о том, чт, jOKer (ok), 08:59 , 26-Сен-20, (82)

column1 jsonb_set column1, abbb,0,rrrr,fdrt , 123 , true , spectator (??), 20:15 , 26-Сен-20, (93) +1

опечатался в первом поле abbb - bbb, spectator (??), 20:16 , 26-Сен-20, (94)

К сожалению, это немножечко не то Я, в свое время, тоже увидел эту функцию и бы, jOKer (ok), 20:56 , 26-Сен-20, (96) –1

похоже что вы очень мало писали запросов для постгрес раз не знаете как обновить, spectator (??), 21:03 , 26-Сен-20, (97)

Еще раз обновить-то можно Это как раз не проблема Вопрос где именно обновлять, jOKer (ok), 21:16 , 26-Сен-20, (99)
Подумайте зачем сделали целую функцию jsonb_set если мы можем спокойно оперирова, spectator (??), 22:17 , 26-Сен-20, (104)
Как раз пользовался Однако имел при этом проблему при обновлении объемных доку, jOKer (ok), 23:22 , 26-Сен-20, (107)

Попробуйте все же научиться читать Один раз покажу, дальше сами select jsonb, Аноним (9), 20:34 , 26-Сен-20, (95) –3

gt оверквотинг удален А если твой документ мегабайт этак дцать, так и будешь , jOKer (ok), 21:10 , 26-Сен-20, (98)

Где тут таскание по сети jsonb_set делается на стороне postgresql сервера , Аноним (9), 22:01 , 26-Сен-20, (101) +1

Не уверен Факт, что PostgreSQL при всех раскладах будет обновлять поле только ц, jOKer (ok), 22:58 , 26-Сен-20, (105) –3

На сервер отправляется sql-запрос, клиенту приходит результат его выполнения js, Аноним (9), 06:22 , 27-Сен-20, (112)

А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в update, Аноним (9), 22:03 , 26-Сен-20, (102)

Очень смешно Шутник Ладно, за индуса извините, погорячился , jOKer (ok), 23:59 , 26-Сен-20, (108)

каким это образом по-вашему update работающий исключительно на сервере будет т, edo (ok), 05:49 , 28-Сен-20, (120)

Да, тут я, похоже, не прав Сейчас сличил версии официальных документаций начин, jOKer (ok), 21:50 , 26-Сен-20, (100) –1

Максимальный размер документа в монге 8211 16 МБ ну, если ее не перекомпилят, phil (??), 22:16 , 28-Сен-20, (127)

Увеличивать эту константу имеет смысл только есть у вас много ОЗУ, потому что он, jOKer (ok), 20:09 , 30-Сен-20, (132)

учитывая, что у большинства продуктов процесс ДОработки бесконечный, монга умест, лютый жабби__ (?), 12:14 , 26-Сен-20, (87)

sqlite удобнее для разработки, но никак не эффективнее , AleksK (ok), 21:23 , 24-Сен-20, (25)

Не сказал бы что он удобнее учитывая что ничего не умеет толком и инструментов п, ВХОД (?), 22:33 , 24-Сен-20, (28)
У вот таких эффективных пацанчиков, вроде тебя, на мобильниках тоже стоит эффект, Страшный Аноним (?), 23:30 , 24-Сен-20, (31)

Аналогов то SQLite по сути вообще нет на мобильниках, Аноним (35), 00:54 , 25-Сен-20, (35)
у сверх эффективных даже оракля встречается , Sw00p aka Jerom (?), 01:00 , 25-Сен-20, (36)
Что такой агрессивный Тебя web-разработчики били что ли А для чего тебе СУБД н, AleksK (ok), 08:37 , 25-Сен-20, (52)

А у тебя к адресной книге на телефоне прямо несколько клиентов подключаются Глу, Аноним (74), 20:11 , 25-Сен-20, (74) –1

приветик ударникам криокамерыhttps wiki termux com wiki Postgresqlбез рута, ре, mmrnmhrm (?), 23:31 , 27-Сен-20, (115)

в моей практике mongodb был менее стабилен под большой нагрузкой , InuYasha (??), 13:26 , 25-Сен-20, (62) –1

назови, пожалуста, количество записей в хранилище и частоту обращенийвидел людей, mmrnmhrm (?), 23:36 , 27-Сен-20, (116)

Не помню Монги занимали порядка 50-100ГБ данных на штуку, к каждой обращалась п, InuYasha (??), 12:27 , 28-Сен-20, (125)

Вот storage engines так и не завезли , Catwoolfii (ok), 19:36 , 24-Сен-20, (11) –6

Не совсем Если говорить чуть более абстрактно, то FDW умеет очень много Может н, funny.falcon (?), 06:32 , 25-Сен-20, (45) +1
Это палка о двух концах Любая абстракция усложняет оптимизацию А костылями и п, Аноним (48), 08:05 , 25-Сен-20, (50) +1

Кроме trusted extension всё выглядит как нужные и полезные кому-то вещи А вот, Аноним (17), 19:51 , 24-Сен-20, (17)

Тут просто не совсем понятно написано, никаких явных списков там нет, trusted , Аноним (12), 21:02 , 24-Сен-20, (24)
Это упрощает разработку Не от суперюзера же миграции запускать в стейджинг-сред, Аноним (48), 08:08 , 25-Сен-20, (51)

Надеюсь, добавят в грядущую версию 20 10 самого лучшего и мейнстримого дистрибут, DEF (?), 20:03 , 24-Сен-20, (19)

вроде говорили, что последняя версия - 10-ка, Аноним (20), 20:20 , 24-Сен-20, (20) +1

Как так, уже ж 11 в бете , Аноним (92), 14:34 , 26-Сен-20, (92)

Мейнстримное лучшим не бывает В лучших дистрибутивах не нужно гадать успеет ли , ВХОД (?), 22:38 , 24-Сен-20, (29) +3
10 ка вроде последняя, если вы действительно про самого лучшего и мейнстримого , a (??), 23:10 , 24-Сен-20, (30) –3

Да я уже понял, что ты пишешь из Бадена , YetAnotherOnanym (ok), 01:10 , 25-Сен-20, (38)

не из , а с и не Бадена , а Бодуна , garrick (?), 10:01 , 25-Сен-20, (54) +2

20 10 ubuntu зачем гадать добавят или нет https www postgresql org download , Аноним (63), 13:30 , 25-Сен-20, (63) +2

Какой ppa На дворе 2020 и docker образ PostgreSQL ставится в 3 клика , Аноним (122), 11:08 , 28-Сен-20, (122) –1

apt postgresql org, Аноним (83), 09:23 , 26-Сен-20, (83) +1

А чем сейчас модно визуально в базе ковыряться А то pgAdmin 4 скатился совсем , tim2k (ok), 11:17 , 25-Сен-20, (55) +1

У нас все на DataGrip перешли Универсальная тула, Аноним (56), 11:54 , 25-Сен-20, (56) +1

Free 30-day trial - 124 Я тоже год назад пытался фронтендик хоть какой-нибудь , InuYasha (??), 13:31 , 25-Сен-20, (64) –1

EAP-шки бесплатные https www jetbrains com datagrip nextversion Формально это, Аноним (9), 16:21 , 25-Сен-20, (68) –1
Забыл начать писать , Gogi (??), 14:09 , 26-Сен-20, (91)

Фуфло у вас, а не тула - для пальцедрочеров Большинство операций делается мыш, Gogi (??), 14:06 , 26-Сен-20, (88)

dbeaver ничего так, поддерживает всё помаленьку Может не быть фич из узко заточ, Аноним (57), 12:18 , 25-Сен-20, (59) +8

если он такой умный, почему ни в одних репах его нет судя по репологи, это арч,, бедный буратино (ok), 07:03 , 26-Сен-20, (81) –4

Может быть потому что не нужны репы для того, что распаковывается из архива и ра, Аноним (84), 10:47 , 26-Сен-20, (84)

Обязательно нужны Как минимум, нужно поставить жаву, не удалить её по autoremov, Аноним (118), 02:22 , 28-Сен-20, (118)

Есть на Flathub https flathub org apps details io dbeaver DBeaverCommunity, Аноним (103), 22:04 , 26-Сен-20, (103) +1
У dbeaver две редакции, бесплатная и платная, не много людей хотят спонсировать , Аноним (42), 00:30 , 27-Сен-20, (110)

https en wikipedia org wiki Comparison_of_database_tools, Аноним (60), 12:50 , 25-Сен-20, (60)
Sequeler https github com Alecaddd sequeler get-it-from-the-elementary-os-app, Аноним (65), 14:08 , 25-Сен-20, (65)

Он только для линукса, Gogi (??), 14:06 , 26-Сен-20, (89) –1

Ну так и используй линукс А вообще, в винде WSL завезли, мб и на нём взлетит, Аноним (123), 11:28 , 28-Сен-20, (123)

TOra, SysA (?), 14:13 , 25-Сен-20, (66) –1

Support Oracle MySQL - жидковатенько и не имеет к топику никакого отношения, Gogi (??), 14:08 , 26-Сен-20, (90)

DBeaver очень хороший вариант , Avator (ok), 17:09 , 25-Сен-20, (70)
Визульно скучно psql service name , worldmind (?), 18:45 , 25-Сен-20, (73) +1
все как обычно psql, rshadow (ok), 20:26 , 25-Сен-20, (75) +1
https tableplus com , ivanpetrov (ok), 00:19 , 28-Сен-20, (117)
psql Вы инвалид, зачем вам визуально , Аноним (118), 02:22 , 28-Сен-20, (119)
https github com parihaaraka sqt, andrey (??), 17:30 , 29-Сен-20, (129)
Можно попробовать Kexi из состава Calligra , Аноним (130), 18:10 , 29-Сен-20, (130)

Сообщения [Сортировка по времени | RSS]

1. "Релиз СУБД PostgreSQL 13" +26 +/–

Сообщение от DEF (?), 24-Сен-20, 19:05

Замечательная БД. Лучшая в мире, имхо.

Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз СУБД PostgreSQL 13" +5 +/–

Сообщение от Аноним (2), 24-Сен-20, 19:08

Постгря объективно лучшая, так что имхо тут лишнее

Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз СУБД PostgreSQL 13" +6 +/–

Сообщение от Аноним (7), 24-Сен-20, 19:19

Ну, это вы за своё имхо так говорите!  :)

Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз СУБД PostgreSQL 13" –7 +/–

Сообщение от Аноним (12), 24-Сен-20, 19:41

Постгрес, там «с» в конце.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

18. "Релиз СУБД PostgreSQL 13" +7 +/–

Сообщение от Аноним (18), 24-Сен-20, 19:57

«с» не в конце, а в начале SQL

Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (21), 24-Сен-20, 20:21

А в слове "прогресс" тоже в начале? Или это такой троллинг? Вообще надо секту "постгрЭ" законожательно запретить как сделали с АУЕ.

Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (18), 24-Сен-20, 21:28

> А в слове "прогресс" тоже в начале?
Если ты заметил, в "прогресс" нет суффикса SQL.

Ответить | Правка | Наверх | Cообщить модератору

22. "Релиз СУБД PostgreSQL 13" +13 +/–

Сообщение от Аноним (12), 24-Сен-20, 20:46

Нет, https://ru.wikipedia.org/wiki/PostgreSQL
Слово postgres образовано от "Post Ingres" и изначально никакого SQL он не поддерживал.
После реализации SQL авторы решили что название postgres95 не очень и что будет прикольно написать "PostgresSQL", а ещё круче — убрав дубль S, "PostgreSQL" и произносить «Пост-Грэс-Кью-Эл», о чём теперь жалеют и считают что это было ошибкой, потому что при увеличении сообщества приходится всё время объяснять новичкам правильное название базы :-)

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

23. "Релиз СУБД PostgreSQL 13" +2 +/–

Сообщение от Аноним (23), 24-Сен-20, 20:57

https://www.postgresql.org/docs/current/history.html#AEN187
Berkley POSTGRES (с 1986) → Postgres95 (с 1994) → PostgreSQL (с 1996).
«Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.» ←→ «Многие продолжают говорить Postgres, ибо традиция и произносимее. Приемлимость «Postgres» в качестве синонима высока.»

Когда-то думали переименовать в Postgres: https://wiki.postgresql.org/wiki/Postgres
Но консенсуса не было: https://www.postgresql.org/about/policies/project-name/
> The name Postgres is an accepted alias for the PostgreSQL project. However it is an alias or nickname and is not the official name of the project. Per Dave Page, PostgreSQL Core Team:
>    Following recent discussions on a name change for the project, it has become clear that consensus within the community will never be reached. In light of this, the core team have discussed the matter in depth and decided that the project shall continue to use the name PostgreSQL, but accept the use of Postgres as an alias.
С употреблением Britain и Great Britain то же самое (но там Great добавили, чтобы остров Britain с Britanny не перепутать, оба от лат. Brittania).

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

27. "Релиз СУБД PostgreSQL 13" –4 +/–

Сообщение от mr.Clin (?), 24-Сен-20, 22:23

Ага, настолько классная что Uber с неё свинтил на MySQL + свой напилиник по понятным причинам...

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

42. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (42), 25-Сен-20, 04:20

Свой напильник можно было и в постгресе сделать, это чисто политическое решение, о миграции.

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз СУБД PostgreSQL 13" +9 +/–

Сообщение от Аноним (48), 25-Сен-20, 07:59

Если бы Uber провёл то самое исследование производительности на этапе проектирования структуры базы, а не когда все уперлось в обновление индексов, можно было бы и никуда не валить, а спроектировать базу с применением головного мозга. У них там была таблица с индексом почти на каждое поле, и она обновлялась по сто раз в секунду. Это им ещё повезло, что внутреннее устройство innodb подошло под их кейс, и что они не обновляли primary key (вот тут бы innodb вообще обвалился - там pk=oid грубо говоря). Но эта проблема ещё валидная (и с тех пор в ее в pg не то, чтобы целиком решили, но существенно смягчили), все остальное вообще из разряда «не осилили».

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

61. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от mr.Clin (?), 25-Сен-20, 13:12

Там не только проблема со вторичными индексами была, с VACUUM проблема более-менее тоже актуальная на больших объёмах данных при постоянной перезаписи.

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от zzz (??), 26-Сен-20, 04:45

Проблема там была только с мозгами и откатами. Устроить миграцию MySQL - PostreSQL - MySQL без нагрузочного тестирования, на шару - это надо быть или идиотом, или умным распильщиком.

Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (48), 26-Сен-20, 05:01

Про вакуум в постгресе знают вроде вообще все, даже те, кто запросов сложнее select * from table в свой жизни ни разу не писал. Кроме разработчиков Убера, видимо, для которых это оказалось новостью когда все прилегло.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

80. "Релиз СУБД PostgreSQL 13" –4 +/–

Сообщение от n242name (?), 26-Сен-20, 06:21

Как может быть лучше субд у которой это говновакуум вообще существует?
А дебильные имена объектов в UPPERCASE?
НаверноеЕстьРазница?
ИЛИВСЕТАКИНИКАКОЙРАЗНИЦЫНЕТ?

Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (42), 27-Сен-20, 00:21

В postgres регистронезависимые имена.

Ответить | Правка | Наверх | Cообщить модератору

111. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от n242name (?), 27-Сен-20, 01:41

> В postgres регистронезависимые имена.
но регистр он не запоминает.. в отличии от MySQL
можно смело забыть про PascalCase

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Страшный Аноним (?), 24-Сен-20, 23:33

Куда там Oracle, Ms SQL Server и IBM DB2, да? Это просто мальчики для биться по сравнению с вакуумным Postgre? Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

41. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (42), 25-Сен-20, 04:18

Правильно писать Postgres

Ответить | Правка | Наверх | Cообщить модератору

46. "Релиз СУБД PostgreSQL 13" +13 +/–

Сообщение от Pers (??), 25-Сен-20, 07:19

Лучший ответ на заданный вопрос )

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (57), 25-Сен-20, 12:15

Да там и с русским проблема, не то что с названиями.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

69. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от InuYasha (??), 25-Сен-20, 17:01

Правильно - рисовать слоника )

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

76. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (57), 25-Сен-20, 20:47

А при чём здесь РНР?

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от InuYasha (??), 28-Сен-20, 12:29

Аноны, вы вконец ослепли??
https://www.postgresql.org/media/img/about/press/elephant.png
Это логотип!

Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз СУБД PostgreSQL 13" –2 +/–

Сообщение от 1 (??), 25-Сен-20, 12:15

Чтоб продавать постгре вместо оракла.
Но на больших БД - поддержка постгри дороже оракловской.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

67. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (12), 25-Сен-20, 14:46

Очевидно что вы не разбираетесь в теме раз даже не знаете как база правильно называется :-)

Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Виталий (??), 29-Сен-20, 09:20

>Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?
За тем, что Postgres отжал у Oracle рынок, а это добивает последних.
Я еще в 2011-2012 RBC переводил с Oracle на Postgres, экономия была огромной как по лицензиям так и по простоте поддержки и стоимости обслуживания.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

131. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от ptr128 (?), 30-Сен-20, 11:49

Чем легче перенести код с PL/SQL на PL/pgsql - тем больше пользователей это сделают.
А практическая бесшовная поддержка иных языков - очень сильное конкурентное преимущество. После длительного общения с MS по поводу активного использования R в MS SQL, они сами рекомендовали перейти на PostgreSQL. Производительность выросла на порядок!
Если конкретней, то при необходимости нескольких миллионов вызовов функций на R при обработке данных, вместо 14 часов на MS SQL стали укладываться в 70 минут на PostgreSQL на том же сервере.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

33. "Релиз СУБД PostgreSQL 13" –3 +/–

Сообщение от Страшный Аноним (?), 24-Сен-20, 23:38

Кстати, как там в Postgre с партиционированием, завезли полноценное или еще на 5 лет отставили?
Для тех, кто тогда ходил под стол, сообщаю, что партиционированию в Oracle больше 20 лет.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

40. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от funny.falcon (?), 25-Сен-20, 03:48

На ручном приводе я ещё в 2003 партицирование делал пользуясь наследованием, которое вроде ещё с 80х в постгресе.
Но, конечно, это было не так удобно, как полностью поддержанное самой базой.

Ответить | Правка | Наверх | Cообщить модератору

43. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (42), 25-Сен-20, 04:21

В postgres, да, завезли.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

49. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (48), 25-Сен-20, 08:02

Давно уже есть.
С десятой версии вроде.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

53. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (53), 25-Сен-20, 09:54

Это только в энтерпрайзной версии, которая многие миллионы стоит, которую только супер корпорации позволить себе могут. В MSSQL больше фич за 300к.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

71. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от лолшто (?), 25-Сен-20, 17:49

Лучшая в мире БД для лучшего в мире юзкейса

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

86. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от лютый жабби__ (?), 26-Сен-20, 12:11

>Лучшая в мире, имхо.
JSON там считай что нет. Соответственно, лучшая средневековая СУБД.
В Монге, кстати, уже давно и транзакции завезли (хотя они по прежнему не нужны в 98% случаев).

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

106. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Cykooz (ok), 26-Сен-20, 23:09

В монге так реализовали транзакции, что и оставшиеся 2% не выйдет использовать. Они работают только в реплик-сетах, и при этом не работают на шардированных коллекциях (обещали позднее сделать). А без шардирования монга полезна в редких случаях.

Ответить | Правка | Наверх | Cообщить модератору

113. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от лютый жабби__ (?), 27-Сен-20, 11:44

>Они работают только в реплик-сетах
Я вообще ХЗ как может быть невасян СУБД без реплик... учитывая время разворачивания бэкапа на несколько ТБ. Любое железо смертно.
А про шардирование, вот прямо никак без него? У меня базы по 1-3ТБ нормально ворочаются без него...
Так что "оставшиеся 2% не выйдет использовать" это false.

Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Cykooz (ok), 27-Сен-20, 13:24

> Я вообще ХЗ как может быть невасян СУБД без реплик... учитывая время
> разворачивания бэкапа на несколько ТБ. Любое железо смертно.
Если придираться к словам, то репликация - это не то же самое что бекап, и не заменяет его.
Необходимость поднимать реплик-сет, только ради транзакций, доставляет немного хлопот в процессе разработки. С классическими RDB достаточно запустить их в минимальной конфигурации и весь функционал будет работать.
> А про шардирование, вот прямо никак без него? У меня базы по
> 1-3ТБ нормально ворочаются без него...
Думаю и другие базы данных вполне будут нормально ворочаться на таких объёмах без "шардирования".
Но в случае с монгой, простое шардирование из коробки - это главная киллер-фича. Если вам оно не нужно, то необходимость использовать именно MongoDB чаще всего сомнительна.

Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от лютый жабби__ (?), 28-Сен-20, 11:02

>Если придираться к словам
-"реплики редко нужны"
-нет, реплики нужны всегда, т.к. время разворачивания бэкапа несколько дней
-репликация - это не то же самое что бекап, и не заменяет его
хрень пишешь...

"простое шардирование из коробки - это главная киллер-фича"
ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к. я внезапно не использую киллер-фичу

Ответить | Правка | Наверх | Cообщить модератору

124. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Cykooz (ok), 28-Сен-20, 12:06

> хрень пишешь...
В чём хрень? Если у тебя приложение (или хакеры) испоганит данные в базе, то эти изменения будут во всех репликах базы очень быстро. Т.е. репликация ни каким образом не позволит тебе откатить состояние базы на какой-то момент в прошлом, когда всё было нормально. Для такого нужен бекап. Поэтому я и написал, что репликация не заменяет бекапы.
> ой, мля, ну всё, срочно побежал монгу менять на всех проектах, т.к.
> я внезапно не использую киллер-фичу
Я и не прошу тебя отказываться от Монги в уже написанном проекте (сам уже 8 лет пилю такой). Я говорил исключительно про выбор базы данных для ещё ненаписанного приложения.

Ответить | Правка | Наверх | Cообщить модератору

3. "Релиз СУБД PostgreSQL 13" –5 +/–

Сообщение от YetAnotherOnanym (ok), 24-Сен-20, 19:13

> Реализована концепция заслуживающих доверия дополнений
Ждём появления магазина дополнений, которые можно ставить в один клик. А то несовременный он какой-то, этот Постгрес.

Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Рева RarogCmex Денис (?), 24-Сен-20, 19:13

Куда же без монетизации и монетизации на монетизацию?

Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз СУБД PostgreSQL 13" +2 +/–

Сообщение от Аноним (12), 24-Сен-20, 19:43

https://pgxn.org/about/

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

37. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от YetAnotherOnanym (ok), 25-Сен-20, 01:07

> https://pgxn.org/about/
О, круто! А дыры, дыры-то есть? А то ж дополнение без дыр - это какое-то неполноценное дополнение.

Ответить | Правка | Наверх | Cообщить модератору

44. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (42), 25-Сен-20, 04:22

Как напишешь — так и будет.

Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Рева RarogCmex Денис (?), 24-Сен-20, 19:13

Неплохая бд под свои цели (тяжелые приложения под реляционрую базу данных). Понятно, что в ряде случаев тот же sqlite, mongodb или redis -- на порядки эффективнее.
Выбирать нужно по техзаданию базу данных, и не париться ;)

Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз СУБД PostgreSQL 13" +5 +/–

Сообщение от Аноним (6), 24-Сен-20, 19:15

sqlite на порядки эффективнее - это интересная идея. Удобнее и компактнее - да, но вот эффективнее...

Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз СУБД PostgreSQL 13" +4 +/–

Сообщение от Аноним (8), 24-Сен-20, 19:31

В РЯДЕ СЛУЧАЕВ эффективнее
внимательнее надо с областью определения утверждений

Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Sw00p aka Jerom (?), 24-Сен-20, 19:43

даже не В РЯДЕ СЛУЧАЕВ, а в В НЕКОТОРЫХ СЛУЧАЯХ.

Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз СУБД PostgreSQL 13" +3 +/–

Сообщение от Аноним (8), 24-Сен-20, 19:49

В исходном утверждении стоит именно в ряде случаев.
Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать получившееся. Это же типичный демагогический прием.

Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Sw00p aka Jerom (?), 25-Сен-20, 00:49

> Не понимаю, что за мода выкидывать/заменять часть утверждений и затем горячо критиковать
> получившееся. Это же типичный демагогический прием.
И ну и как тут не ответить? Мой комент был всего лишь поправкой, и с исходным коментом я согласен, что СУБД нужно выбирать исходя из необходимых и достаточных требований (по ТЗ). А далее немного демагогии (можете пропустить) ....

Давайте посмотрим на одно из определений слова Ряд (из вики):
"""
Ряд — некоторое, немалое количество, например «ряд стран».
"""
Тут пояснения нужны, что словом Ряд можно заменить слово Некоторое? Эту моду придумал не я.

Ответить | Правка | Наверх | Cообщить модератору

9. "Релиз СУБД PostgreSQL 13" +6 +/–

Сообщение от Аноним (9), 24-Сен-20, 19:31

Для записной книжки в телефоне - эффективнее.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

85. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от x3who (?), 26-Сен-20, 11:31

> Для записной книжки в телефоне - эффективнее.
Таких инсталляций на порядки больше, чем корпоративных БД. Так что правильно говорить о незначительном количестве юзкейсов, в которых sqlite всё ещё уступает Постгресу и Ораклу.

Ответить | Правка | Наверх | Cообщить модератору

10. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (9), 24-Сен-20, 19:34

Кстати, не припомню ни одного случая, когда монга была бы именно эффективнее. Проще в разработке и поддержке - да.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

15. "Релиз СУБД PostgreSQL 13" +6 +/–

Сообщение от Аноним (15), 24-Сен-20, 19:43

В основном в разработке чужого бюджета

Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 25-Сен-20, 01:31

Это только потому, видимо, что вам _пока_ не требовалось от СУБД умение работать в состоянии расщепления (Partition Tolerance). Как только это произойдет... ну, тогда вы точно запомните случай, когда MongoDB оказалась более эффективной. =)

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

47. "Релиз СУБД PostgreSQL 13" +4 +/–

Сообщение от Аноним (48), 25-Сен-20, 07:38

Монга первая в мире СУБД с partition tolerance, ога) Мы такое кастомной MySQL proxy делали ещё в бородатом 2006 году.
Могна удобна тем, кто не хочет думать, хочет раз-два и в продакшен, mongodb is web scale (c), sharding is a secret ingredient (c). Для стартапов, написанных моральными индусами для развода инвесторов на бабки, самое то.
А если задуматься, то фигня какая-то: schemaless, подразумевающий разреженность, но при этом единственный тип индекса это btree! Инвертированных индексов нет, банальных хешей даже нет, блум фильтров нет, оптимизатора запросов нет, даже планирования запросов как такового нет, населена роботами. И действительно, зачем, давайте делать фуллскан, ведь у нас горизонтально масштабируется, всегда можно докупить ещё серверов... на задачи, где банальный постгрес с одной таблицей вида (id serial PK, data JSONB gin/gist) справится и на одном.

Ответить | Правка | Наверх | Cообщить модератору

72. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от jOKer (ok), 25-Сен-20, 18:13

>[оверквотинг удален]
> mongodb is web scale (c), sharding is a secret ingredient (c).
> Для стартапов, написанных моральными индусами для развода инвесторов на бабки, самое
> то.
> А если задуматься, то фигня какая-то: schemaless, подразумевающий разреженность, но при
> этом единственный тип индекса это btree! Инвертированных индексов нет, банальных хешей
> даже нет, блум фильтров нет, оптимизатора запросов нет, даже планирования запросов
> как такового нет, населена роботами. И действительно, зачем, давайте делать фуллскан,
> ведь у нас горизонтально масштабируется, всегда можно докупить ещё серверов... на
> задачи, где банальный постгрес с одной таблицей вида (id serial PK,
> data JSONB gin/gist) справится и на одном.
А можно меньше слюней, пены и соплей, и побольше того, что называется "взвешенным мнением технического эксперта". Мы же все-таки на профильном ресурсе, а не форме имени хеллоу ворлд. Договорились? Ну вот и хорошо.
А теперь господин как бэ эксперт, раз уж вы тут ляпнули про JSONB, то дайте в студию хотя бы один запрос, который позволит обновить _отдельный атрибут_ (!) json-документа, сохраненного в поле этого типа. И атрибута не верхнего уровня, потому что это-то как раз PostgreSQL умеет, а где-нибудь поглубже. К примеру, вот есть у вас портянка вида {"aaa" 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 45679}}]}, и нужно обновить "fdrt". Постройте-ка запросик, а? И желательно БЕЗ привлечения тех расширений PostgreSQL, которые пишут умные системные программисты для вполне себе КОММЕРЧЕСКИХ продуктов. Ну, как, справитесь?
Сразу могу сказать, что навряд ли. А вот монга способна этот фокус проделать даже с документами размером в несколько Гб _на любом_ уровне вложенности.

PS Тут уже в треде прозвучало мнение, что каждому инструменту своя предметная область и свои проблемы, которые этот инструмент закрывает. Соглашусь с этим утверждением. У MongoDb своя область, а у PostgreSQL - своя. И прежде чем пытаться померится сами знаете чем, стоит это обстоятельство учесть. И разумно для своих проблем инструмент выбрать.
PPS Кстати, "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL. Так что на вашем месте я бы ими не козырял. Не стоит.

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (48), 26-Сен-20, 04:53

О, вот и фанбои подтянулись.
>  обновить _отдельный атрибут_ (!)
https://www.postgresql.org/docs/13/functions-json.html
Все можно, читай внимательно.
>  "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL.
Чего?

Ответить | Правка | Наверх | Cообщить модератору

82. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 26-Сен-20, 08:59

> https://www.postgresql.org/docs/13/functions-json.html
> Все можно, читай внимательно.
Похоже, что читать внимательно стоит как раз вам. Там ни пол-слова нет о том, что можно обновить атрибуты на уровне вложенности больше чем одного, самого первого. Теоретики, такие теоретики.
Еще раз: если вы такой умный, то попробуйте составить запрос, который обновит ровно один атрибут - "fdrt" вот у этого документа, хранящегося в поле типа JSONB:
{
  "aaa" 5,
  "bbb": [{
    "fff": 12345,
    "rrrr": {
      "fdrt": 45679
    }
  }]
}
Запрос в студию!

>>  "банальные хэши" сто лет в обед в PostgreSQL считаются индексом не рекомендуемым к применению. Внезапно. А все потому что не проходят в WAL.
> Чего?
Того. В силу определенной архитектуры, операции с индексом типа "hash" не попадают в WAL. Собственно, как я понимаю, единственная причина почему этот тип индекса вообще не приговорили, так это потому, что его использует сам PostgreSQL на системных таблицах. А вот для прикладников его употребление не рекомендовано.
Конкретно в мануалах есть такая информация:
"Операции с хеш-индексами в настоящее время не проходят через WAL, так что после аварийной остановки базы данных может потребоваться перестроить хеш-индексы командой REINDEX. Кроме того, изменения в хеш-индексах после начальной копии не переносятся при потоковой или файловой репликации, так что в последующих запросах они будут давать неправильные ответы. По этим причинам настоятельно рекомендуется не использовать их."

Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от spectator (??), 26-Сен-20, 20:15

column1 = jsonb_set(column1, '{abbb,0,rrrr,fdrt}','123', true)

Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от spectator (??), 26-Сен-20, 20:16

опечатался в первом поле: abbb -> bbb

Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от jOKer (ok), 26-Сен-20, 20:56

> опечатался в первом поле: abbb -> bbb
К сожалению, это немножечко не то.
Я, в свое время, тоже увидел эту функцию и было обрадовался, и как оказалось - зря. Потому что основную проблему - обновление части документа JSON _на_стороне_сервера_ эта функция не решает. Она _просто_ возвращает видоизмененные данные. Причем, я даже не поручусь, что эти изменения не происходят на стороне клиента.
То есть вот эта, трижды клятая в этом треде MongoDB, способна на стороне сервера обновить часть JSON-документа, а PostgreSQL похоже, без доработок-расширений, может обновлять только поле JSONB целиком. Что доставляет проблемы, если ваш документ изрядно большой, допустим в несколько мегабайт. Потому что в этом случае, вам придется весь этот документ забрать по сети на клиент, сделать там его обновление, и потом целиком опять отправить на сервер. А это и дополнительный трафик, и потеря производительности.

Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от spectator (??), 26-Сен-20, 21:03

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

Ответить | Правка | Наверх | Cообщить модератору

99. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 26-Сен-20, 21:16

> похоже что вы очень мало писали запросов для постгрес раз не знаете
> как обновить значение
> не стоит спорить не зная основ
Еще раз: обновить-то можно. Это как раз не проблема. Вопрос где именно обновлять. Потому что обновлять на стороне клиента - контрпродуктивно...
Ладно-ладно, не будем спорить. Но вот когда (и если) вы столкнетесь с ситуацией о которой я говорю (документ в JSONB-поле размером в несколько десятков мегабайт) и начнете просаживать производительность - вспомните тогда меня.

Ответить | Правка | Наверх | Cообщить модератору

104. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от spectator (??), 26-Сен-20, 22:17

Подумайте зачем сделали целую функцию jsonb_set если мы можем спокойно оперировать json-ом на стороне клиента?
Ладно, люди которые хотели узнать можно ли обновлять jsonb в postgres уже наверняка разобрались, а вам, возможно, хочется найти оправдание почему вы им не пользуетесь

Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 26-Сен-20, 23:22

> вам, возможно, хочется найти оправдание почему вы им не пользуетесь
Как раз пользовался. Однако имел при этом проблему: при обновлении объемных документов JSON внутри поля типа JSONB сильно падала производительность микросервиса. После того, как микросервис был переписан под работу с монгой, производительность поднялась на пару порядков. Попутно получил профит при обновлении нескольких значений в документе одновременно.
Хотя вот при работе с небольшими документами проблем у PostgreSQL мной замечено не было. Это и заставило меня предположить что операция обновления данных внутри поля типа JSONB полностью или частично выполняется на стороне клиента.

Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

95. "Релиз СУБД PostgreSQL 13" –3 +/–

Сообщение от Аноним (9), 26-Сен-20, 20:34

> попробуйте составить запрос
Попробуйте все же научиться читать. Один раз покажу, дальше сами.
=# select jsonb_set('{
  "aaa": 5,
  "bbb": [{
    "fff": 12345,
    "rrrr": {
      "fdrt": 45679
    }
  }]
}'::jsonb, '{"bbb", 0, "rrrr", "fdrt"}'::text[], '100500'::jsonb);
                           jsonb_set
---------------------------------------------------------------
{"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]}

Update уж сами допишете.
> операции с индексом типа "hash" не попадают в WAL
Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно пишется. То ли с 9-й версии, то ли с 10-й.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

98. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 26-Сен-20, 21:10

>[оверквотинг удален]
>
>
>     jsonb_set
> ---------------------------------------------------------------
>  {"aaa": 5, "bbb": [{"fff": 12345, "rrrr": {"fdrt": 100500}}]}
> Update уж сами допишете.
>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.
А если твой документ мегабайт этак ~дцать, так и будешь тягать его по сети туда-сюда, а? Там где монга _на стороне сервера_ обновит документ из коллекции передавая по сети только определение операции, ты будешь тягать документ _целиком_. Что ты там писал про индусов постом выше? Так вот, с таким подходом, ты именно этот индус и есть.

Ответить | Правка | Наверх | Cообщить модератору

101. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (9), 26-Сен-20, 22:01

Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.

Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз СУБД PostgreSQL 13" –3 +/–

Сообщение от jOKer (ok), 26-Сен-20, 22:58

> Где тут таскание по сети? jsonb_set делается на стороне postgresql сервера.
>jsonb_set делается на стороне postgresql сервера
Не уверен.
Факт, что PostgreSQL при всех раскладах будет обновлять поле только целиком.
Следовательно ему нужно взять содержимое, обновить его, и положить обратно. Это само по себе затратно. Но этого мало, потому что не известно где именно происходит само обновление. Я думаю все же, что на клиенте. Возможно только частично. И я думаю так же, что все это время сервер держит блокировку, и вот это-то и может объяснить просадку быстродействия, которая начинает наблюдаться, при обновлении полей с объемными JSON-документами внутри....
Блин, но вы таки заронили зерно сомнения, да.
Буду копать глубже. Сейчас спорить не буду, - фактов ни "за", ни "против" у меня нет. Возможно отпишусь позже, когда пройдусь сканером трафика, что бы посмотреть что именно отправляется на клиент и обратно.

Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (9), 27-Сен-20, 06:22

На сервер отправляется sql-запрос, клиенту приходит результат его выполнения. jsonb_set это постгресовская функция, выполняемая на сервере. Никаких промежуточных штук типа коллбэков в протоколе нет, я когда-то писал свою реализацию постгрес-клиента с нуля (будете смеяться, для php! Но с асинхронкой - еще до того, как появился ReactPHP и подобное, был только pecl/libevent), можете мне поверить на слово :-)
Другое дело, что со стороны сервера в mongodb действительно обновление части документа может быть более эффективным - когда постгресу надо распарсить весь jsonb, выполнить jsonb_set и потом сохранить все целиком, в монге могут быть оптимизации. Но я не уверен, что они там есть :-)
Да и в целом производительность поиска меня волнует намного больше, чем производительность обновления.

Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (9), 26-Сен-20, 22:03

А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в update переписать не можете.
update tablename set fieldname = jsonb_set(fieldname, $1, $2), где $1 = path, $2 = new value.
И кто тут индус?

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

108. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 26-Сен-20, 23:59

> А, до меня дошло, что вы даже пример селекта, демонстрируюшего принцип, в
> update переписать не можете.
Очень смешно. Шутник.
> И кто тут индус?
Ладно, за "индуса" извините, погорячился.

Ответить | Правка | Наверх | Cообщить модератору

120. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от edo (ok), 28-Сен-20, 05:49

каким это образом по-вашему update (работающий исключительно на сервере) будет таскать данные на клиента и обратно?
P. S. обновление json на десятки мегабайт в любом случае боль. jsonb ЕМНИП никак проблему не решает.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

100. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от jOKer (ok), 26-Сен-20, 21:50

>> операции с индексом типа "hash" не попадают в WAL
> Омг, давайте еще проблемы с wal fsync из 6-го постгреса вспомним.
> Мануал надо читать в оригинале, а не переводы 10-летней давности. Все давным-давно
> пишется. То ли с 9-й версии, то ли с 10-й.
Да, тут я, похоже, не прав. Сейчас сличил версии официальных документаций: начиная с 10-ой версии, они свое грозное предупреждение, которое я процитировал в переводе, убрали. Так что вероятно эта проблема уже решена. Что же... +1 PostgreSQL в таком случае. =) Я в последний раз столкнулся с этой траблой на 9.6 Там она еще была.

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

127. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от phil (??), 28-Сен-20, 22:16

> А вот монга способна этот фокус проделать даже с документами размером в несколько Гб
Максимальный размер документа в монге – 16 МБ (ну, если ее не перекомпилять)

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

132. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от jOKer (ok), 30-Сен-20, 20:09

Увеличивать эту константу имеет смысл только есть у вас много ОЗУ, потому что она и выбрана-то была, с тем расчетом, что бы документ в ОЗУ поместился с гарантией.
Куда проще (и это официально рекомендованный вариант) использовать для хранения GridFS. В этом случае, документ бьется на чанки, что конечно снижает общую производительность, но не так уж и сильно. Но вот документ при этом, может достигать значительно больших размеров.

Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от лютый жабби__ (?), 26-Сен-20, 12:14

>когда монга была бы именно эффективнее. Проще в разработке и поддержке - да.
учитывая, что у большинства продуктов процесс ДОработки бесконечный, монга уместнее почти всегда. увы и ах...

Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

25. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от AleksK (ok), 24-Сен-20, 21:23

sqlite удобнее для разработки, но никак не эффективнее

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

28. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от ВХОД (?), 24-Сен-20, 22:33

Не сказал бы что он удобнее учитывая что ничего не умеет толком и инструментов под него нет.

Ответить | Правка | Наверх | Cообщить модератору

31. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Страшный Аноним (?), 24-Сен-20, 23:30

У вот таких эффективных пацанчиков, вроде тебя, на мобильниках тоже стоит эффективный PostgreSQL?
Если да, то обращайтесь - у меня друг очень хороший психиатр.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

35. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (35), 25-Сен-20, 00:54

Аналогов то SQLite по сути вообще нет на мобильниках

Ответить | Правка | Наверх | Cообщить модератору

36. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Sw00p aka Jerom (?), 25-Сен-20, 01:00

> У вот таких эффективных пацанчиков
у "сверх эффективных" даже оракля встречается :)

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

52. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от AleksK (ok), 25-Сен-20, 08:37

Что такой агрессивный? Тебя web-разработчики били что ли?
А для чего тебе СУБД на смартфоне? Для хранения локальных данных и настроек? Как только к sqlite подцепляется больше одного клиента вся его "эффективность" улетучивается. Поэтому он подходит для прототипирования при разработке, и хранения локальных данных одного приложения, и то в этом случае зачастую подойдет обычное хранилище ключ-значение. Были ещё варианты его применения, но это была совсем экзотика.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

74. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (74), 25-Сен-20, 20:11

А у тебя к адресной книге на телефоне прямо несколько клиентов подключаются. Глупости не говори.
Оставим в покое телефоны, посмотри какую какашку с akonadi сделали.
Да, sqlite эфективнее во многих местах, но не в вебне откуда ты пришёл.

Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от mmrnmhrm (?), 27-Сен-20, 23:31

приветик ударникам криокамеры
https://wiki.termux.com/wiki/Postgresql
без рута, регистрации и смс

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

62. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от InuYasha (??), 25-Сен-20, 13:26

в моей практике mongodb был менее стабилен под большой нагрузкой.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

116. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от mmrnmhrm (?), 27-Сен-20, 23:36

назови, пожалуста, количество записей в хранилище и частоту обращений
видел людей, серьёзно считающих 30к записей хайлоадом, которому необходим шардинг
постгря такую мелочь перемалывает без индексов, банальным фулсканом

Ответить | Правка | Наверх | Cообщить модератору

125. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от InuYasha (??), 28-Сен-20, 12:27

Не помню. Монги занимали порядка 50-100ГБ данных на штуку, к каждой обращалась пара десятков серверов в реальном времени, т.е. непрерывно, забивая пару мегабит - точно.

Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз СУБД PostgreSQL 13" –6 +/–

Сообщение от Catwoolfii (ok), 24-Сен-20, 19:36

Вот storage engines так и не завезли...

Ответить | Правка | Наверх | Cообщить модератору

45. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от funny.falcon (?), 25-Сен-20, 06:32

Не совсем.
Если говорить чуть более абстрактно, то FDW умеет очень много. Может не полноценная замена storage engines, но зато подходит и для других задач.
Если говорить конкретно, то ЕЩЁ не завезли. Они работают над этим.

Ответить | Правка | Наверх | Cообщить модератору

50. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (48), 25-Сен-20, 08:05

Это палка о двух концах. Любая абстракция усложняет оптимизацию. А костылями и подпорками, как в MySQL, в постгресе не прокатит, там другая культура разработки (точнее, она там присутствует в отличие от). Тут надо и на елку влезть, и не поцарапаться, это непростая задача. Но исследования ведутся.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

17. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (17), 24-Сен-20, 19:51

Кроме "trusted extension" всё выглядит как нужные и полезные кому-то вещи. А вот эти белые списки дополнений как-то выглядят небезопасно.
Если это такие хорошие и полезные дополнения, то и включите их просто в конфиге по-умолчанию. Кому надо те отключат. Зато нерутовым юзерам не надо будет иметь возможность их включать.

Ответить | Правка | Наверх | Cообщить модератору

24. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (12), 24-Сен-20, 21:02

> Список подобных дополнений изначально предопределён и может быть расширен суперпользователем.
Тут просто не совсем понятно написано, никаких явных списков там нет, trusted — это просто _флаг в самом файле с описанием extension_.
> включите их просто в конфиге по-умолчанию
Администратор всегда при установке может отредактировать template1 базу сам сделав всё что ему нужно доступным по умолчанию. Если это сделают авторы postgres то потеряется возможность сделать пустую базу, в ней всегда будут какие-то объекты из предложенных вами расширений, потеряется гибкость.
"trusted extension" это на самом деле очень важная и долгожданная функция для выкаток. Сейчас если сервис использует extension то он не может сам без помощи выкатить схему своей базы, так как для create extension нужен superuser, приходится городить обёртки типа служебных хранимок create_extesion(...) с security definer и т.п. С "trusted extension" это можно будет сделать гораздо проще.

Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (48), 25-Сен-20, 08:08

Это упрощает разработку. Не от суперюзера же миграции запускать в стейджинг-среде. На продакшене особо и не надо, да,

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

19. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от DEF (?), 24-Сен-20, 20:03

Надеюсь, добавят в грядущую версию 20.10 самого лучшего и мейнстримого дистрибутива.

Ответить | Правка | Наверх | Cообщить модератору

20. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (20), 24-Сен-20, 20:20

вроде говорили, что последняя версия - 10-ка

Ответить | Правка | Наверх | Cообщить модератору

92. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (92), 26-Сен-20, 14:34

Как так, уже ж 11 в бете :)

Ответить | Правка | Наверх | Cообщить модератору

29. "Релиз СУБД PostgreSQL 13" +3 +/–

Сообщение от ВХОД (?), 24-Сен-20, 22:38

Мейнстримное лучшим не бывает. В лучших дистрибутивах не нужно гадать успеет ли оно попасть в какую-то там ежегодную циферку - оно туда попадает сразу после выпуска, а до этого попадает в виде бет и rc для тех кому это надо.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

30. "Релиз СУБД PostgreSQL 13" –3 +/–

Сообщение от a (??), 24-Сен-20, 23:10

10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".10 ка вроде последняя, если вы действительно про "самого лучшего и мейнстримого дистрибутива".

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

38. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от YetAnotherOnanym (ok), 25-Сен-20, 01:10

Да я уже понял, что ты пишешь из Бадена.

Ответить | Правка | Наверх | Cообщить модератору

54. "Релиз СУБД PostgreSQL 13" +2 +/–

Сообщение от garrick (?), 25-Сен-20, 10:01

не "из", а "с" и не "Бадена", а "Бодуна" :)

Ответить | Правка | Наверх | Cообщить модератору

63. "Релиз СУБД PostgreSQL 13" +2 +/–

Сообщение от Аноним (63), 25-Сен-20, 13:30

20.10. ubuntu?
зачем гадать добавят или нет: https://www.postgresql.org/download/linux/ubuntu/
добавляем сами ppa и всё.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

122. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (122), 28-Сен-20, 11:08

Какой ppa? На дворе 2020 и docker образ PostgreSQL ставится в 3 клика.

Ответить | Правка | Наверх | Cообщить модератору

83. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (83), 26-Сен-20, 09:23

apt.postgresql.org

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

55. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от tim2k (ok), 25-Сен-20, 11:17

А чем сейчас модно визуально в базе ковыряться? А то pgAdmin 4 скатился совсем.

Ответить | Правка | Наверх | Cообщить модератору

56. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (56), 25-Сен-20, 11:54

У нас все на DataGrip перешли. Универсальная тула

Ответить | Правка | Наверх | Cообщить модератору

64. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от InuYasha (??), 25-Сен-20, 13:31

>Download
Free 30-day trial :-|
Я тоже год назад пытался фронтендик хоть какой-нибудь накрутить. Но уже забыл, на чём остановился )

Ответить | Правка | Наверх | Cообщить модератору

68. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Аноним (9), 25-Сен-20, 16:21

EAP-шки бесплатные. https://www.jetbrains.com/datagrip/nextversion/
Формально это даже не бета, а найтли-билд, но по факту все, кроме новых фич, стабильно.
Обычно есть либо EAP, либо триал очередного релиза в его роли. Если ставить через snap edge channel, можно вообще ничего не заметить.

Ответить | Правка | Наверх | Cообщить модератору

91. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Gogi (??), 26-Сен-20, 14:09

Забыл начать писать? :)

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

88. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Gogi (??), 26-Сен-20, 14:06

Фуфло у вас, а не "тула" - для пальцедрочеров. Большинство операций делается мышой не приходя в сознание.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

59. "Релиз СУБД PostgreSQL 13" +8 +/–

Сообщение от Аноним (57), 25-Сен-20, 12:18

dbeaver ничего так, поддерживает всё помаленьку. Может не быть фич из узко заточенных инструментов, но минимальный набор посмотреть таблички, сессии, запросы позапускать — есть для большинства БД, которые в дикой природе встречаются.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

81. "Релиз СУБД PostgreSQL 13" –4 +/–

Сообщение от бедный буратино (ok), 26-Сен-20, 07:03

если он такой умный, почему ни в одних репах его нет? судя по репологи, это арч, ещё пара мелких дистров... и winget

Ответить | Правка | Наверх | Cообщить модератору

84. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (84), 26-Сен-20, 10:47

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

Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (118), 28-Сен-20, 02:22

Обязательно нужны. Как минимум, нужно поставить жаву, не удалить её по autoremove, поставить приложение как принято в системе, по правильным путям, с иконками, записями в меню, документацией и манами, а потом обновлять его вместе со всем остальным, а не вспоминать где у тебя по системе распихан протухший софт.

Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от Аноним (103), 26-Сен-20, 22:04

Есть на Flathub: https://flathub.org/apps/details/io.dbeaver.DBeaverCommunity

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

110. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (42), 27-Сен-20, 00:30

У dbeaver две редакции, бесплатная и платная, не много людей хотят спонсировать просто так чей-то бизнес, и бесплатно им делать пакеты, а авторам видимо это не интересно плюс так как это java то он просто распаковывается из архива и работает.

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

60. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (60), 25-Сен-20, 12:50

https://en.wikipedia.org/wiki/Comparison_of_database_tools

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

65. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (65), 25-Сен-20, 14:08

Sequeler. https://github.com/Alecaddd/sequeler#get-it-from-the-element...

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

89. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от Gogi (??), 26-Сен-20, 14:06

Он только для линукса

Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (123), 28-Сен-20, 11:28

Ну так и используй линукс!
А вообще, в винде WSL завезли, мб и на нём взлетит

Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз СУБД PostgreSQL 13" –1 +/–

Сообщение от SysA (?), 25-Сен-20, 14:13

TOra

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

90. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Gogi (??), 26-Сен-20, 14:08

* Support Oracle & MySQL - жидковатенько и не имеет к топику никакого отношения

Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Avator (ok), 25-Сен-20, 17:09

DBeaver очень хороший вариант.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

73. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от worldmind (?), 25-Сен-20, 18:45

Визульно скучно: psql 'service=<name>'

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

75. "Релиз СУБД PostgreSQL 13" +1 +/–

Сообщение от rshadow (ok), 25-Сен-20, 20:26

все как обычно... psql

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

117. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от ivanpetrov (ok), 28-Сен-20, 00:19

https://tableplus.com/

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

119. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (118), 28-Сен-20, 02:22

psql. Вы инвалид, зачем вам визуально?

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

129. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от andrey (??), 29-Сен-20, 17:30

https://github.com/parihaaraka/sqt

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

130. "Релиз СУБД PostgreSQL 13" +/–

Сообщение от Аноним (130), 29-Сен-20, 18:10

>А чем сейчас модно визуально в базе ковыряться?
Можно попробовать Kexi из состава Calligra.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Релиз СУБД PostgreSQL 13"	+26 +/–
Сообщение от DEF (?), 24-Сен-20, 19:05
Замечательная БД. Лучшая в мире, имхо.
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Релиз СУБД PostgreSQL 13"	+5 +/–
	Сообщение от Аноним (2), 24-Сен-20, 19:08
	Постгря объективно лучшая, так что имхо тут лишнее
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Релиз СУБД PostgreSQL 13"	+6 +/–
	Сообщение от Аноним (7), 24-Сен-20, 19:19
	Ну, это вы за своё имхо так говорите! :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Релиз СУБД PostgreSQL 13"	–7 +/–
	Сообщение от Аноним (12), 24-Сен-20, 19:41
	Постгрес, там «с» в конце.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	18. "Релиз СУБД PostgreSQL 13"	+7 +/–
	Сообщение от Аноним (18), 24-Сен-20, 19:57
	«с» не в конце, а в начале SQL
	Ответить \| Правка \| Наверх \| Cообщить модератору


	21. "Релиз СУБД PostgreSQL 13"	–1 +/–
	Сообщение от Аноним (21), 24-Сен-20, 20:21
	А в слове "прогресс" тоже в начале? Или это такой троллинг? Вообще надо секту "постгрЭ" законожательно запретить как сделали с АУЕ.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	26. "Релиз СУБД PostgreSQL 13"	+1 +/–
	Сообщение от Аноним (18), 24-Сен-20, 21:28
	> А в слове "прогресс" тоже в начале? Если ты заметил, в "прогресс" нет суффикса SQL.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	22. "Релиз СУБД PostgreSQL 13"	+13 +/–
	Сообщение от Аноним (12), 24-Сен-20, 20:46
	Нет, https://ru.wikipedia.org/wiki/PostgreSQL Слово postgres образовано от "Post Ingres" и изначально никакого SQL он не поддерживал. После реализации SQL авторы решили что название postgres95 не очень и что будет прикольно написать "PostgresSQL", а ещё круче — убрав дубль S, "PostgreSQL" и произносить «Пост-Грэс-Кью-Эл», о чём теперь жалеют и считают что это было ошибкой, потому что при увеличении сообщества приходится всё время объяснять новичкам правильное название базы :-)
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	23. "Релиз СУБД PostgreSQL 13"	+2 +/–
	Сообщение от Аноним (23), 24-Сен-20, 20:57
	https://www.postgresql.org/docs/current/history.html#AEN187 Berkley POSTGRES (с 1986) → Postgres95 (с 1994) → PostgreSQL (с 1996). «Many people continue to refer to PostgreSQL as “Postgres” (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias.» ←→ «Многие продолжают говорить Postgres, ибо традиция и произносимее. Приемлимость «Postgres» в качестве синонима высока.» Когда-то думали переименовать в Postgres: https://wiki.postgresql.org/wiki/Postgres Но консенсуса не было: https://www.postgresql.org/about/policies/project-name/ > The name Postgres is an accepted alias for the PostgreSQL project. However it is an alias or nickname and is not the official name of the project. Per Dave Page, PostgreSQL Core Team: > Following recent discussions on a name change for the project, it has become clear that consensus within the community will never be reached. In light of this, the core team have discussed the matter in depth and decided that the project shall continue to use the name PostgreSQL, but accept the use of Postgres as an alias. С употреблением Britain и Great Britain то же самое (но там Great добавили, чтобы остров Britain с Britanny не перепутать, оба от лат. Brittania).
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	27. "Релиз СУБД PostgreSQL 13"	–4 +/–
	Сообщение от mr.Clin (?), 24-Сен-20, 22:23
	Ага, настолько классная что Uber с неё свинтил на MySQL + свой напилиник по понятным причинам...
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	42. "Релиз СУБД PostgreSQL 13"	+1 +/–
	Сообщение от Аноним (42), 25-Сен-20, 04:20
	Свой напильник можно было и в постгресе сделать, это чисто политическое решение, о миграции.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	48. "Релиз СУБД PostgreSQL 13"	+9 +/–
	Сообщение от Аноним (48), 25-Сен-20, 07:59
	Если бы Uber провёл то самое исследование производительности на этапе проектирования структуры базы, а не когда все уперлось в обновление индексов, можно было бы и никуда не валить, а спроектировать базу с применением головного мозга. У них там была таблица с индексом почти на каждое поле, и она обновлялась по сто раз в секунду. Это им ещё повезло, что внутреннее устройство innodb подошло под их кейс, и что они не обновляли primary key (вот тут бы innodb вообще обвалился - там pk=oid грубо говоря). Но эта проблема ещё валидная (и с тех пор в ее в pg не то, чтобы целиком решили, но существенно смягчили), все остальное вообще из разряда «не осилили».
	Ответить \| Правка \| К родителю #27 \| Наверх \| Cообщить модератору


	61. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от mr.Clin (?), 25-Сен-20, 13:12
	Там не только проблема со вторичными индексами была, с VACUUM проблема более-менее тоже актуальная на больших объёмах данных при постоянной перезаписи.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от zzz (??), 26-Сен-20, 04:45
	Проблема там была только с мозгами и откатами. Устроить миграцию MySQL - PostreSQL - MySQL без нагрузочного тестирования, на шару - это надо быть или идиотом, или умным распильщиком.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от Аноним (48), 26-Сен-20, 05:01
	Про вакуум в постгресе знают вроде вообще все, даже те, кто запросов сложнее select * from table в свой жизни ни разу не писал. Кроме разработчиков Убера, видимо, для которых это оказалось новостью когда все прилегло.
	Ответить \| Правка \| К родителю #61 \| Наверх \| Cообщить модератору


	80. "Релиз СУБД PostgreSQL 13"	–4 +/–
	Сообщение от n242name (?), 26-Сен-20, 06:21
	Как может быть лучше субд у которой это говновакуум вообще существует? А дебильные имена объектов в UPPERCASE? НаверноеЕстьРазница? ИЛИВСЕТАКИНИКАКОЙРАЗНИЦЫНЕТ?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Релиз СУБД PostgreSQL 13"	–1 +/–
	Сообщение от Аноним (42), 27-Сен-20, 00:21
	В postgres регистронезависимые имена.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "Релиз СУБД PostgreSQL 13"	–1 +/–
	Сообщение от n242name (?), 27-Сен-20, 01:41
	> В postgres регистронезависимые имена. но регистр он не запоминает.. в отличии от MySQL можно смело забыть про PascalCase
	Ответить \| Правка \| Наверх \| Cообщить модератору


	32. "Релиз СУБД PostgreSQL 13"	+1 +/–
	Сообщение от Страшный Аноним (?), 24-Сен-20, 23:33
	Куда там Oracle, Ms SQL Server и IBM DB2, да? Это просто мальчики для биться по сравнению с вакуумным Postgre? Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	41. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от Аноним (42), 25-Сен-20, 04:18
	Правильно писать Postgres
	Ответить \| Правка \| Наверх \| Cообщить модератору


	46. "Релиз СУБД PostgreSQL 13"	+13 +/–
	Сообщение от Pers (??), 25-Сен-20, 07:19
	Лучший ответ на заданный вопрос )
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Релиз СУБД PostgreSQL 13"	–1 +/–
	Сообщение от Аноним (57), 25-Сен-20, 12:15
	Да там и с русским проблема, не то что с названиями.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	69. "Релиз СУБД PostgreSQL 13"	–1 +/–
	Сообщение от InuYasha (??), 25-Сен-20, 17:01
	Правильно - рисовать слоника )
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	76. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от Аноним (57), 25-Сен-20, 20:47
	А при чём здесь РНР?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	126. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от InuYasha (??), 28-Сен-20, 12:29
	Аноны, вы вконец ослепли?? https://www.postgresql.org/media/img/about/press/elephant.png Это логотип!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	58. "Релиз СУБД PostgreSQL 13"	–2 +/–
	Сообщение от 1 (??), 25-Сен-20, 12:15
	Чтоб продавать постгре вместо оракла. Но на больших БД - поддержка постгри дороже оракловской.
	Ответить \| Правка \| К родителю #32 \| Наверх \| Cообщить модератору


	67. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от Аноним (12), 25-Сен-20, 14:46
	Очевидно что вы не разбираетесь в теме раз даже не знаете как база правильно называется :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	128. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от Виталий (??), 29-Сен-20, 09:20
	>Кстати, а зачем Postgre из трусов выпрыгивает, пытаясь привязать PL/SQL к своей поделка? За тем, что Postgres отжал у Oracle рынок, а это добивает последних. Я еще в 2011-2012 RBC переводил с Oracle на Postgres, экономия была огромной как по лицензиям так и по простоте поддержки и стоимости обслуживания.
	Ответить \| Правка \| К родителю #32 \| Наверх \| Cообщить модератору


	131. "Релиз СУБД PostgreSQL 13"	+/–
	Сообщение от ptr128 (?), 30-Сен-20, 11:49
	Чем легче перенести код с PL/SQL на PL/pgsql - тем больше пользователей это сделают. А практическая бесшовная поддержка иных языков - очень сильное конкурентное преимущество. После длительного общения с MS по поводу активного использования R в MS SQL, они сами рекомендовали перейти на PostgreSQL. Производительность выросла на порядок! Если конкретней, то при необходимости нескольких миллионов вызовов функций на R при обработке данных, вместо 14 часов на MS SQL стали укладываться в 70 минут на PostgreSQL на том же сервере.
	Ответить \| Правка \| К родителю #32 \| Наверх \| Cообщить модератору


	33. "Релиз СУБД PostgreSQL 13"	–3 +/–
	Сообщение от Страшный Аноним (?), 24-Сен-20, 23:38
	Кстати, как там в Postgre с партиционированием, завезли полноценное или еще на 5 лет отставили? Для тех, кто тогда ходил под стол, сообщаю, что партиционированию в Oracle больше 20 лет.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору