Гораздо более развитый DDL (Data Definition Language) и DCL (data control language): SHOW DATABASES, SHOW TABLES, SHOW CREATE TABLE и т.п.
это не DDL и не DCL. И нигде ниже не была продемонстрирована "гораздо большая развитость".
Data Control Language
...
помимо того, что это не DCL, а чем, собственно, не устроили эквиваленты psql (\l, \d и иже с ними)?
Эти вещи, скорее, забота клиента, и вставлять их в язык - решение неоднозначное (при этом, конструкции вроде SHOW CREATE TABLE, выдающие в виде DML запроса определение объекта, действительно полезны и в PG их подчас не хватает).
FLUSH TABLES
FLUSH HOSTS
...
а объясните людям без 20+ лет опыта в MySQL, на кой хрен вообще эти команды нужны?
ALTER TABLE table_name CHANGE COLUMN
Круто, CHANGE COLUMN умеет переименовывать и сразу тип менять. Развитость налицо. А ежели изменение типа чуть сложнее, чем INT -> BIGINT, по какие правилам преобразование идет? В недоразвитом постгресе можно указать явно через USING.
Офигеть, я не могу добавить новую колонку после другой конкретной колонки, а могу добавить только в конец...
Офигеть, а еще INSERT AFTER row нельзя сделать, 19 век прямо. Порядок колонок в таблице тоже такое себе явление (кто в курсе, что стандарт по этому поводу говорит?).
Если сильно приперло, поменять можно через пересоздание таблицы (CREATE TABLE AS SELECT, например).
В InnoDB (сюрприз!) перестановка колонок вызовет перезапись всей таблицы.
REPLACE INTO
А INSERT ... ON CONFLICT типа только многословностью не угодил?
Угу, в частном (и довольно глупом) случае, который покрывает REPLACE, он неприятно многословен. При этом такой же синтаксис есть и в mysql, только более недоразвитый
А есть в mysql аналог MERGE? (врочем, в PG ее ждали минимум лет 5... олды вспомнят еще как в 8.4 обсуждалось)
Пока писал нужные мне SQL-statements для работы с JSON, пришлось мучать ChatGPT несколько часов подряд, которого я довёл, наверное, до седины — постоянно сыпались те или иные ошибки, интуитивно-очевидные конструкции с JSON не работают.
"Все хреново, но что, не скажу." Можно конкретики? Ибо синтаксис JSONB у них сильно шагнул вперед за последние годы (я сам давно отстал от жизни уже). Можно делать такое:
-- Where jsonb_field was {}, it is now {"a": [{"b": 1}]}
UPDATE table_name SET jsonb_field['a'][0]['b'] = '1';
Почему-то в PostgreSQL по умолчанию нельзя аутентифицироваться с паролем.
зато как прекрасны эти GRANT ... TO user@127.0.0.1 в мускуле. Только бы не запутаться, с какого ипшника ходишь...
Необходимость вакуумирования
Единственная адекватная претензия. Время показывает, что архитектура MVCC в постгресе не самая удачная. Все zheap не дождемся...
INSERT INTO the_table ... ON CONFLICT вместо REPLACE INTO
жесть... Ни то, ни другое не стандарт, и внезапно в мускуле есть свой INSERT ON CONFLICT ! А вот MERGE, между прочим, стандарт.
Чатгпт сказало, видите ли, что "PostgreSQL делает акцент на строгом следовании стандартам SQL и обеспечении высокой надежности и целостности данных, даже если это означает отказ от некоторых нестандартных или потенциально небезопасных возможностей", хотя прямо на сайте у них написано: "PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features".
Ну и жаловались бы с таким уровнем аргументации чатгпт, он бы вам посочувствовал.
Для показа юзеру что 1000, что 100000 документов это одинаковое количество - "слишком много", поэтому для оценки качества нужны таки промаркированные запросы.
Лимиты делали?
Кэш не грели, слова для запросов каждый раз брали рандомом, обычно по 1000 запросов (если они работали слишком медленно - уменьшали до 100)
можно все-таки дисперсию или min-max время увидеть?
И попробуйте на каком-то одном списке тестировать все движки (а то мало ли, вдруг кто-то не стал парсить xml и названия тегов стали словами, причем супер частыми, и такое слово попалось в запросе).
Странная статья. Где описание методологии? Сделали непонятно что, получили какие-то результаты - толку от них кому-то?
(ниже акцент на Postgres, т.к. с ним я хорошо знаком, но сами вопросы, думаю, актуальны для более-менее всех движков)
Версии ПО? (ссылка на postgres fts в англ версии ведет на доки от 9.5, что наводит на подозрения)
Как конфигурировали? Конкретно по postgres: основные параметры postgresql.conf? Какого типа индексы (gist/gin)? Конфигурация FTS? (вообще, некоторые утверждения ваши вызывают недоумение, например, про поддержку языков: вы точно отличаете языки от кодировок? Вы же дочитали в документации postgres до раздела про словари FTS?)
Запросы - код, плз. Какие именно ключевые слова использовались и в каком количестве? Надеюсь, хотя бы одинаковые для всех движков? Запросы выдают хотя бы примерно одинаковый результат? Ранжирование было?
Техническая достоверность: БД в память помещается? прогревали кеш? запросы one term / 3 term OR - с одними ключевиками (очень большие сомнения конкретно для postgres вызывают именно эти результаты - хотелось бы видеть конкретику)?
Статистическая достоверность - сколько раз прогоняли? дисперсия какая?
Оценка результатов поиска (выше уже про качество писали, но хотя бы количественно - если один нашел 100 документов, а другой 10000 по одному и тому же запросу - сравнивать как-то некорректно).
При помощи аналогичных вычислений можно показать, что на самом деле обертоны — это целые кратные основной частоты
"Поверьте на слово, в конце концов, вы же не побежите ради этого покупать книженцию за 245 долларов", ага.
Вообще-то, собственные частоты круглой мембраны - это нули функций Бесселя, которые вообще ни разу не кратны друг другу, даже для простейшего случая радиальных колебаний (функция J0)
БД размером 3GB, дамп в формате plain весит порядка 14-17GB.
Эм… Что это такие у вас за данные?
Куча огромных текстовых полей, что ли? Разве что в этом случае внутреннее сжатие даст такую разницу (и то сомневаюсь).
Несовпадение количество строк в некоторых таблицах в исходной и целевой БД, после выполнения pg_restore (Исходная БД не использовалась в процессе копирования, если, что ).
не верю (с)
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью. Было бы гораздо полезнее разобраться, если что-то такое действительно может иметь место.
Но plain огромный размер дампа.
Включите сжатие (custom/directory сжаты по умолчанию, отсюда вся разница).
К слову об экономии места: копия БД весит заведомо больше, чем любой дамп. Так что сомнительная у вас экономия даже на этом.
Плюс простота организации и управления хранением
Не знаю…
Если свежесть данных некритична (или БД можно отключить от пользователей), что-то проще dump/restore придумать сложно.
Если важна полнота данных (как, например, при онлайн миграции на новую версию), то дамп схемы + логическая репликация с живой БД — канонический способ, описанный примерно везде.
Во вторых-и это самое неприятное, были случаи несовпадения исходной и целевой БД при восстановлении из дампа.
Какие еще несовпадения? Вы ожидали совпадения на какой момент?
В начале дампа pg_dump начинает serializable транзакцию, все, что произошло в исходной БД после, в дамп не попадает.
Думаете, копия через create database как-то по-другому работает?
В третьих-время, сначала на создание дампа, потом на восстановление БД из дампа.
Неужели репликация быстрее? Хмм…
В итоге единственное преимущество — экономия на месте для дампов (временных).
Да, с zheap что-то совсем заглохло… У вас там никто не в курсе, какие планы?
Зато MERGE в PG15, видимо, все же будет.
Мне лично еще очень нравится патч Incremental Materialized View Maintenance. В свое время в Oracle активно использовали подобную фичу в сочетании с DBLINK.
Шекспир очень часто переходит на прозу, в то же Гамлете, когда не остается ни поэтической формы, ни размера. Не говоря уже про рифму — ее у Шекспира и так днем с огнем не найдешь.
Свобода высказываний и мнений означает что вам не имеют право вредить при вашей деятельности, но не означает что вам все обязаны с ней помогать (даже за деньги).
Вам, наверное, знакомо понятие «сетевой нейтралитет»?
Следует ли провайдеру отключить мне интернет, если он не согласен с байтами, которые я пересылаю по его проводу?
Это какой-то позор... (с)
это не DDL и не DCL. И нигде ниже не была продемонстрирована "гораздо большая развитость".
помимо того, что это не DCL, а чем, собственно, не устроили эквиваленты psql (\l, \d и иже с ними)?
Эти вещи, скорее, забота клиента, и вставлять их в язык - решение неоднозначное (при этом, конструкции вроде SHOW CREATE TABLE, выдающие в виде DML запроса определение объекта, действительно полезны и в PG их подчас не хватает).
а объясните людям без 20+ лет опыта в MySQL, на кой хрен вообще эти команды нужны?
Круто, CHANGE COLUMN умеет переименовывать и сразу тип менять. Развитость налицо. А ежели изменение типа чуть сложнее, чем INT -> BIGINT, по какие правилам преобразование идет? В недоразвитом постгресе можно указать явно через USING.
Офигеть, а еще INSERT AFTER row нельзя сделать, 19 век прямо. Порядок колонок в таблице тоже такое себе явление (кто в курсе, что стандарт по этому поводу говорит?).
Если сильно приперло, поменять можно через пересоздание таблицы (CREATE TABLE AS SELECT, например).
В InnoDB (сюрприз!) перестановка колонок вызовет перезапись всей таблицы.
А INSERT ... ON CONFLICT типа только многословностью не угодил?
Угу, в частном (и довольно глупом) случае, который покрывает REPLACE, он неприятно многословен. При этом такой же синтаксис есть и в mysql, только более недоразвитый
А есть в mysql аналог MERGE? (врочем, в PG ее ждали минимум лет 5... олды вспомнят еще как в 8.4 обсуждалось)
"Все хреново, но что, не скажу." Можно конкретики? Ибо синтаксис JSONB у них сильно шагнул вперед за последние годы (я сам давно отстал от жизни уже). Можно делать такое:
А еще есть jsonpath...
зато как прекрасны эти
GRANT ... TO user@127.0.0.1в мускуле. Только бы не запутаться, с какого ипшника ходишь...Единственная адекватная претензия. Время показывает, что архитектура MVCC в постгресе не самая удачная. Все zheap не дождемся...
жесть... Ни то, ни другое не стандарт, и внезапно в мускуле есть свой INSERT ON CONFLICT ! А вот MERGE, между прочим, стандарт.
Чатгпт сказало, видите ли, что "PostgreSQL делает акцент на строгом следовании стандартам SQL и обеспечении высокой надежности и целостности данных, даже если это означает отказ от некоторых нестандартных или потенциально небезопасных возможностей", хотя прямо на сайте у них написано: "PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features".
Ну и жаловались бы с таким уровнем аргументации чатгпт, он бы вам посочувствовал.
Как эти библиотеки справляются с патологическими регулярками типа
(a?)^na^n? (пример для n=5 —/a?a?a?a?a?aaaaa/ ~ "aaaaa")Смысл существования re2 как раз в отсутствии патологий бектрекинга (https://swtch.com/~rsc/regexp/regexp1.html)
Да вот не осиливает:
(cap_net_raw, setuid)
А для чего нужны стигматы святой Терезе? Они ведь ей тоже не нужны. Но они ей желанны. – Вот-вот! (с)
Челенж такой.
Потому что нужны десятичные цифры. Сконвертировать потом из двоичной в десятичную, пожалуй, задача вычислительно более сложная
Ничоси, чудеса да и только :O
https://en.wikipedia.org/wiki/Double-precision_floating-point_format#Precision_limitations_on_integer_values
Лимиты делали?
можно все-таки дисперсию или min-max время увидеть?
И попробуйте на каком-то одном списке тестировать все движки (а то мало ли, вдруг кто-то не стал парсить xml и названия тегов стали словами, причем супер частыми, и такое слово попалось в запросе).
Странная статья. Где описание методологии? Сделали непонятно что, получили какие-то результаты - толку от них кому-то?
(ниже акцент на Postgres, т.к. с ним я хорошо знаком, но сами вопросы, думаю, актуальны для более-менее всех движков)
Версии ПО? (ссылка на postgres fts в англ версии ведет на доки от 9.5, что наводит на подозрения)
Как конфигурировали? Конкретно по postgres: основные параметры postgresql.conf? Какого типа индексы (gist/gin)? Конфигурация FTS?
(вообще, некоторые утверждения ваши вызывают недоумение, например, про поддержку языков: вы точно отличаете языки от кодировок? Вы же дочитали в документации postgres до раздела про словари FTS?)
Запросы - код, плз. Какие именно ключевые слова использовались и в каком количестве? Надеюсь, хотя бы одинаковые для всех движков? Запросы выдают хотя бы примерно одинаковый результат? Ранжирование было?
Техническая достоверность: БД в память помещается? прогревали кеш? запросы one term / 3 term OR - с одними ключевиками (очень большие сомнения конкретно для postgres вызывают именно эти результаты - хотелось бы видеть конкретику)?
Статистическая достоверность - сколько раз прогоняли? дисперсия какая?
Оценка результатов поиска (выше уже про качество писали, но хотя бы количественно - если один нашел 100 документов, а другой 10000 по одному и тому же запросу - сравнивать как-то некорректно).
а почему должна? рациональные обертона там только для мод (n,0)/(0,m) получаются
"Поверьте на слово, в конце концов, вы же не побежите ради этого покупать книженцию за 245 долларов", ага.
Вообще-то, собственные частоты круглой мембраны - это нули функций Бесселя, которые вообще ни разу не кратны друг другу, даже для простейшего случая радиальных колебаний (функция J0)
Эм… Что это такие у вас за данные?
Куча огромных текстовых полей, что ли? Разве что в этом случае внутреннее сжатие даст такую разницу (и то сомневаюсь).
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью. Было бы гораздо полезнее разобраться, если что-то такое действительно может иметь место.
Включите сжатие (custom/directory сжаты по умолчанию, отсюда вся разница).
К слову об экономии места: копия БД весит заведомо больше, чем любой дамп. Так что сомнительная у вас экономия даже на этом.
Не знаю…
Если свежесть данных некритична (или БД можно отключить от пользователей), что-то проще dump/restore придумать сложно.
Если важна полнота данных (как, например, при онлайн миграции на новую версию), то дамп схемы + логическая репликация с живой БД — канонический способ, описанный примерно везде.
Какие еще несовпадения? Вы ожидали совпадения на какой момент?
В начале дампа pg_dump начинает serializable транзакцию, все, что произошло в исходной БД после, в дамп не попадает.
Думаете, копия через create database как-то по-другому работает?
Неужели репликация быстрее? Хмм…
В итоге единственное преимущество — экономия на месте для дампов (временных).
Зато MERGE в PG15, видимо, все же будет.
Мне лично еще очень нравится патч Incremental Materialized View Maintenance. В свое время в Oracle активно использовали подобную фичу в сочетании с DBLINK.
ОпроверготрицаетКогда уже новостники разберутся в паре простых глаголов?..
Зря не говорили. Ниже написал, но повторю: неграм коворкинг может отказать по причине того, что они негры?
Публичная оферта? Не слышали? Дискриминация? Не слышали?
Может магазин не пускать негров или геев, скажем, по своему усмотрению?
Удивительно, до чего можно договориться…
Вам, наверное, знакомо понятие «сетевой нейтралитет»?
Следует ли провайдеру отключить мне интернет, если он не согласен с байтами, которые я пересылаю по его проводу?