После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 18. Обновления для новой ветки будут выходить в течение пяти лет до ноября 2030 года. Поддержка PostgreSQL 13.x, самой старой из поддерживаемых веток, будет прекращена 13 ноября...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63877
Вообще круто, из университетского проекта так раскрутиться:
https://en.wikipedia.org/wiki/PostgreSQL
Как думаешь, уже можно на нее с Ingres SQL переходить?
по ссылке чушь какая-то написана
российская ж разработка
В России есть компания, которая участвует в разработке PG, причем вклад весьма не маленький, насколько знаю (хотя и вряд ли радикально большой), но это точно не российская разработка.
can't tell trolling or just stupidСигаев и Бартунов многое сделали для Постгреса, причем ещё начиная с 90х, когда они были студентами МГУ и им понадобилось эффективно работать с разреженными астрономическими данными: hstore, GIN/GiST, tsvector/tsquery, позже JSONB. Но всё это в классическом духе международного опенсорса - присоединились к открытой разработке проекта, зародившегося в Беркли под руководством профессора Стоунбрейкера. Бартунов более известен в сообществе, потому что у него с английским хорошо и язык подвешен, но по коду основной вклад Сигаева.
>io_uring (io_method=io_uring), поддерживаемый начиная с ядра Linux 5.1Только он там разваливался, и починили это только к 5.4
Думаю, ещё лет 10 стоит подождать, прежде чем использовать io_uring. Но то, что сабж подтянули до уровня конкурентов, не может не радовать, конечно. Ещё бы он так не распухал.
почему это? уже достаточно много проектов используют, проблем со стабильностью не замечается.
другое дело, что появился новый класс эксплойтов, дыры в io_uring периодически чинят. но если вы не запускаете на сервере недоверенный код (а на сервере бд обычно не запускают), то вас это и не касается
..насчет подтянули до уровня конкурентов
каждый раз, читая новости про PG, что-нибудь находишь такое - а оно же в MSSQL всегда было!В данной новости это - прошлых (OLD) и текущих (CURRENT) в returning (в mssql output, deleted. и inserted.)
а до сих пор нет PIVOT, только через какое-то расширение. Имхо, это вообще базовая возможность SQL.
прямо сейчас переводим какую-то е****нину на динамическом SQL с PIVOT с MSSQL на PG
и ничего хорошего в этом нет
PostgreSQL - бд как швецарский нож, шикрано подходит для большинства современных задач.
Мало современных software продуктов которые с каждым релизом становяться только лучше. Второй такой пожалуй только Java, кстати 25я вышла тоже в этом месяце, что вдвойне приятней.
Ну, не больше, чем sqlite, на самом деле. А, всё, увидел про java.
>Ну, не больше, чем sqliteАга, только без geospacial, timeseries и векторов, fulltext search и типов данных а ля jsonb убившие монгу )
кластера там всякие, репликации вообще зло ))>вcё, увидел про java
увидел - беги учи, сразу после того как про базы почитаешь.
Так sqLITE же, а не sqlEVERYTHING
Поэтому sqlite и не швейцарский нож, а просто складной нож.
... который подходит для 95% задач.Для остального есть Оракле & МS SQL Server. ))
https://opennet.ru/62511-database
почитай как этот рейтинг строиться, так можно подумать что python лучший язык на свете, по тому, что его детям легче преподавать преподавателям в школе (типизации нет, многопоточности нет, управления памяти нет, облостей видимости нет и ОПА... благодаря этой педагогической простоте, Python взлетает в рейтингах как будто это вершина инженерной мысли. Не язык, а мечта — ни тебе указателей, ни тебе строгой типизации, ни тебе боли от сегфолтов. Всё как в сказке: написал print("Hello, world") — и ты уже программист.А потом эти же рейтинги начинают использовать в корпорациях как аргумент: "Python — самый популярный, значит, самый лучший". Ну да, конечно. По этой логике, TikTok — вершина культурного развития, а доширак — гастрономический шедевр.
И ведь удобно: не надо объяснять студентам, что такое const, volatile, RAII, или почему malloc — это не игрушка. Просто покажи for i in range(10):, и все счастливы. А если что-то не работает — ну, это же интерпретатор, он сам разберётся. Или не разберётся.
Так и живём: язык, придуманный для автоматизации мелких задач, теперь преподают как основу программирования. А потом удивляемся, почему выпускники не знают, что такое стек вызовов, или зачем нужны mutex'ы, и думают что NoSQL- это такая база данных )
Так питон хорош в своей нише - писать скриптики, управляющие и не только, проблема что он вдруг хайпанул и его используют в хайлоаде даже, это не проблема языка самого по себе.
Я люто хохтнул когда увидел питон в вакансии на хайлоад инжинера одной крупной компании. Это кринж.
Вот встроить питон куда нибудь, чтобы просто и легко под капотом конфигурить аппу - это норм, а вот писать на нем стэналон приложение, которое что-то там люто вычисляет на процессоре - не норм.
Внезапно, если не уходить от топика, питон это язык номер 2 для хранимых процедур после PL/pgSQL
>Внезапно, если не уходить от топика, питон это язык номер 2 для хранимых процедур после PL/pgSQLкто будет использовать plpython если он unsafe?!
ты всем разрабам superuser от пользователя выдаш?дефакто все используют PL/pgSQL - а все остальное это статистические девиации
> и его используют в хайлоаде дажеТак хайлоад небось из-за питона.
Про Джоули забыл упомянуть, которыми эта питонофилия обеспечивается.
Учившие паскаль становились серьёзными специалистами и годными разработчиками, способными освоить любые среду и язык, а учащие питон пригодны только в качестве девопсов и иных вариаций battleslave.
> Учившие паскаль становились серьёзными специалистами и годными разработчиками, способными
> освоить любые среду и язык, а учащие питон пригодны только в
> качестве девопсов и иных вариаций battleslave.В качестве devops'ов маловероятно, там компетенций в python'е не достаточно, ни разу.
const и volatile — костыли из C, а не вершина просветления. RAII - парадигма, есть даже в Python (context managers), просто с GC она не так нужна. Так что твои страдания — не про язык, а про то, что тебе CS не объяснили. Перестань быть школоло, почитай про парадигмы и архитектуры — поймёшь, что язык тут ни при чём.PS Строгая типизация в C? скажи ещё, что void* - это тип безопасности. В C компилятор половину приведений молча проглотит, а UB потом прилетит в рантайме. В Python, кстати, с 3.11 mypy и pydantic гоняют типы строже, чем твой си - только без сегфолтов.
Java стоит на месте
>Java стоит на местеНа месте языка с хорошей обратной совместимостью, стройной моделью типов, отличной производительностью на котором написаны почти все современные big data решения: Kafka, Cassandra, Hadoop, DynamoDb, Kinesis и фремворки для работы с ними Spark, Flink
Лучшие IDE Idea, Eclipse
Про jira, confluence, jenkins и миллионы мобильных приложений вообще молчу
Хорошо так стоит, даже не знаю, есть ли язык который близко бы встать смог
Ну, вот кстати респект джаве, даже за факт того что возраст приближается к сишке, а джава по прежнему актуальная и развивается. Куда там расту и прочим, пусть все эти современные язычки просуществуют хоть столько же, сколько уже сейчас существует джава, хотя бы.
Это ты про то, что разработчики Java только к 7 версии поняли, что через switch-case можно string гонять?
Ну справедливости ради все эти биг-дата решения самые мощные не потому что джава быстрый язык, а потому что в этих продукта реализовано грамотное масштабирование и можно сервис раскидать на тысячи машин по всему миру.
Если ты напрмер разработчик, то вместо того чтобы ставить кафку для опытов, гораздо лучше поставить redpanda и получить x10 быстродействие на отдельно взятой своей машине.
>Ну справедливости ради все эти биг-дата решения самые мощные не потому что джава быстрый язык, а потому что в этих продукта реализовано грамотное масштабирование и можно сервис раскидать на тысячи машин по всему миру.Эти решения быстрые по тому что java машина позволяет грамотным разработчикам создавать достаточно производительный хорошо масштабируемые системы.
>Если ты напрмер разработчик, то вместо того чтобы ставить кафку для опытов, гораздо лучше поставить redpanda и получить x10 быстродействие на отдельно взятой своей машине.
Если ты разработчик, то ставить не нужно - используй test containers того, что на проекте
>>Ну справедливости ради все эти биг-дата решения самые мощные не потому что джава быстрый язык, а потому что в этих продукта реализовано грамотное масштабирование и можно сервис раскидать на тысячи машин по всему миру.
> Эти решения быстрые по тому что java машина позволяет грамотным разработчикам создавать
> достаточно производительный хорошо масштабируемые системы.Миф. Все проблемы низкой производительности сотфра реализованого на jvm закрываются большим кол-вом железа. Собственно все эти масштабные кластеры появляются тогда, когда: а) вертикального масстабироваться уже некуда; б) назрела необходимость обеспечить отказоустойчивость.
>>Если ты напрмер разработчик, то вместо того чтобы ставить кафку для опытов, гораздо лучше поставить redpanda и получить x10 быстродействие на отдельно взятой своей машине.
> Если ты разработчик, то ставить не нужно - используй test containers того, что на проектеС затащенной ранее туда jvm гадостью не особо умным архитектором, или вообще безо всякого архитектора джуниором или разрабом без адекватной компетенции.
Всё перечисленное - тормозной мусор. И протащившие всё это корпорастсы те ещё вредители.
У меня сообщения прилетают в кафке за 5ms! Какой нафиг тормазнутый?
То есть всего 100 раундтрипов в секунду? Понятно, что за раундтрип можно слона послать, но что делать, если надо больше?
Или допустим представь себе цепочку из 10-12 воркеров... 10-12 хопов туда, 10-12 хопов назад - это 20-24 хопа или в твоём случае 100-120мс... Круть? Круть...
> У меня сообщения прилетают в кафке за 5ms! Какой нафиг тормазнутый?Ещё какой тормазнутый, твои 5ms без fsync - просто медленное, жрущее за зря память недоразумение.
Не, мне вообще-то java вполне себе нравится (А как "экосистема JVM*" - так и более чем "вполне" - тот же groovy - вполне себе "python done right") - но вот насчет "стройной системы типов" шутка смешная вышла.
> Не, мне вообще-то java вполне себе нравится (А как "экосистема JVM*" -
> так и более чем "вполне" - тот же groovy - вполне
> себе "python done right") - но вот насчет "стройной системы типов"
> шутка смешная вышла.Про "экосистему" расскажи сисадминам, которые вынуждены с 10-ток разных старых и новых версий jvm держать и оскрипчивать их из-за всяких умников, которые запихали в bmc серверов жавааплеты для доступа к консолям.
Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже разных вендоров и версий, распиханными по контейнерам.
>> Не, мне вообще-то java вполне себе нравится (А как "экосистема JVM*" -
>> так и более чем "вполне" - тот же groovy - вполне
>> себе "python done right") - но вот насчет "стройной системы типов"
>> шутка смешная вышла.
> Про "экосистему" расскажи сисадминам, которые вынуждены с 10-ток разных старых и новых
> версий jvm держать и оскрипчивать их из-за всяких умников, которые запихали
> в bmc серверов жавааплеты для доступа к консолям.А вот если бы они их делали на сервелате или вот флеше! Уууух!
> Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах
> выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже
> разных вендоров и версий, распиханными по контейнерам.Открою секрет - им пофиг. Вот прям настолько пофиг - что просто пофиг. Вот менеджерам, которые видят счета - может быть чуть менее пофиг, но если выбирать между ненаписанным кодом на крестах и вот работающем на жаве - выбор немножко так очевиден.
>>> Не, мне вообще-то java вполне себе нравится (А как "экосистема JVM*" -
>>> так и более чем "вполне" - тот же groovy - вполне
>>> себе "python done right") - но вот насчет "стройной системы типов"
>>> шутка смешная вышла.
>> Про "экосистему" расскажи сисадминам, которые вынуждены с 10-ток разных старых и новых
>> версий jvm держать и оскрипчивать их из-за всяких умников, которые запихали
>> в bmc серверов жавааплеты для доступа к консолям.
> А вот если бы они их делали на сервелате или вот флеше!
> Уууух!Как выпилили весь флеш и сервелат, так и жвм туда дорога. Благо, поумнели и на серверах догадались и распихали html консоли на canvas'е.
>> Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах
>> выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже
>> разных вендоров и версий, распиханными по контейнерам.
> Открою секрет - им пофиг. Вот прям настолько пофиг - что просто
> пофиг. Вот менеджерам, которые видят счета - может быть чуть менее
> пофиг, но если выбирать между ненаписанным кодом на крестах и вот
> работающем на жаве - выбор немножко так очевиден.Себе открывай такие секреты, нормальным людям не всё равно. А толковый спец понимает, что бесполезный расход памяти можно убрать и запросить выгоду за профит выразить в повышении ему ЗП.
>[оверквотинг удален]
>>>> так и более чем "вполне" - тот же groovy - вполне
>>>> себе "python done right") - но вот насчет "стройной системы типов"
>>>> шутка смешная вышла.
>>> Про "экосистему" расскажи сисадминам, которые вынуждены с 10-ток разных старых и новых
>>> версий jvm держать и оскрипчивать их из-за всяких умников, которые запихали
>>> в bmc серверов жавааплеты для доступа к консолям.
>> А вот если бы они их делали на сервелате или вот флеше!
>> Уууух!
> Как выпилили весь флеш и сервелат, так и жвм туда дорога. Благо,
> поумнели и на серверах догадались и распихали html консоли на canvas'е.Охтыж! То есть не "жава плохая" - а все соответствующие технологии этого периода по современным меркам "ниочень"?
>>> Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах
>>> выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже
>>> разных вендоров и версий, распиханными по контейнерам.
>> Открою секрет - им пофиг. Вот прям настолько пофиг - что просто
>> пофиг. Вот менеджерам, которые видят счета - может быть чуть менее
>> пофиг, но если выбирать между ненаписанным кодом на крестах и вот
>> работающем на жаве - выбор немножко так очевиден.
> Себе открывай такие секреты, нормальным людям не всё равно. А толковый спец
> понимает, что бесполезный расход памяти можно убрать и запросить выгоду за
> профит выразить в повышении ему ЗП.Ох, закончите хелловрот на ассемблере переписывать - озолотитесь! А пока в вилларибо переписывают- в виллабаджо ява - от инфраструктуры до бизнес-логики - работает.
>[оверквотинг удален]
>>>>> шутка смешная вышла.
>>>> Про "экосистему" расскажи сисадминам, которые вынуждены с 10-ток разных старых и новых
>>>> версий jvm держать и оскрипчивать их из-за всяких умников, которые запихали
>>>> в bmc серверов жавааплеты для доступа к консолям.
>>> А вот если бы они их делали на сервелате или вот флеше!
>>> Уууух!
>> Как выпилили весь флеш и сервелат, так и жвм туда дорога. Благо,
>> поумнели и на серверах догадались и распихали html консоли на canvas'е.
> Охтыж! То есть не "жава плохая" - а все соответствующие технологии этого
> периода по современным меркам "ниочень"?Я не говорил о java, он как язык программирования имеет право на жисть и его в принципе можно вылечить если пренебречь обратной совместимостью со всякой понаписанной всячиной. Речь шла о jvm, который изначально был нинужной нинужностью, ради эфемерной и мало кому нужной кроссплатформенности.
Что до флеш, то он появился потому-что в браузерах на 6 лет был тупо застой через монополию ie сформирован. Ну а сервилат вообще был мёртворождённым.
Так что это не технологии того времени были современными, а застой технологический породил этих выкидышей.>[оверквотинг удален]
>>>> разных вендоров и версий, распиханными по контейнерам.
>>> Открою секрет - им пофиг. Вот прям настолько пофиг - что просто
>>> пофиг. Вот менеджерам, которые видят счета - может быть чуть менее
>>> пофиг, но если выбирать между ненаписанным кодом на крестах и вот
>>> работающем на жаве - выбор немножко так очевиден.
>> Себе открывай такие секреты, нормальным людям не всё равно. А толковый спец
>> понимает, что бесполезный расход памяти можно убрать и запросить выгоду за
>> профит выразить в повышении ему ЗП.
> Ох, закончите хелловрот на ассемблере переписывать - озолотитесь! А пока в вилларибо
> переписывают- в виллабаджо ява - от инфраструктуры до бизнес-логики - работает.Ты басни не рассказывай, всякие хадупы, касандры и еластиксёрчи уже умерли - спасибо за mvp, дальше им крематорий истории.
>[оверквотинг удален]
>>>> А вот если бы они их делали на сервелате или вот флеше!
>>>> Уууух!
>>> Как выпилили весь флеш и сервелат, так и жвм туда дорога. Благо,
>>> поумнели и на серверах догадались и распихали html консоли на canvas'е.
>> Охтыж! То есть не "жава плохая" - а все соответствующие технологии этого
>> периода по современным меркам "ниочень"?
> Я не говорил о java, он как язык программирования имеет право на
> жисть и его в принципе можно вылечить если пренебречь обратной совместимостью
> со всякой понаписанной всячиной. Речь шла о jvm, который изначально был
> нинужной нинужностью, ради эфемерной и мало кому нужной кроссплатформенности.Ну а вот... llvm - нужно, или те же иайцы, вид в профиль?
> Что до флеш, то он появился потому-что в браузерах на 6 лет
> был тупо застой через монополию ie сформирован. Ну а сервилат вообще
> был мёртворождённым.
> Так что это не технологии того времени были современными, а застой технологический
> породил этих выкидышей.Так на чем надо было писать-то, чтоб сейчас "админы с жавой в bmc проблем не имели"? Вариант переписать вот весь IE в хром в 2001 году - не предлагать.
>[оверквотинг удален]
>>>> пофиг. Вот менеджерам, которые видят счета - может быть чуть менее
>>>> пофиг, но если выбирать между ненаписанным кодом на крестах и вот
>>>> работающем на жаве - выбор немножко так очевиден.
>>> Себе открывай такие секреты, нормальным людям не всё равно. А толковый спец
>>> понимает, что бесполезный расход памяти можно убрать и запросить выгоду за
>>> профит выразить в повышении ему ЗП.
>> Ох, закончите хелловрот на ассемблере переписывать - озолотитесь! А пока в вилларибо
>> переписывают- в виллабаджо ява - от инфраструктуры до бизнес-логики - работает.
> Ты басни не рассказывай, всякие хадупы, касандры и еластиксёрчи уже умерли -
> спасибо за mvp, дальше им крематорий истории.Ah, irony...
>[оверквотинг удален]
>>>> Как выпилили весь флеш и сервелат, так и жвм туда дорога. Благо,
>>>> поумнели и на серверах догадались и распихали html консоли на canvas'е.
>>> Охтыж! То есть не "жава плохая" - а все соответствующие технологии этого
>>> периода по современным меркам "ниочень"?
>> Я не говорил о java, он как язык программирования имеет право на
>> жисть и его в принципе можно вылечить если пренебречь обратной совместимостью
>> со всякой понаписанной всячиной. Речь шла о jvm, который изначально был
>> нинужной нинужностью, ради эфемерной и мало кому нужной кроссплатформенности.
> Ну а вот... llvm - нужно, или те же иайцы, вид в
> профиль?Ты когда для себя раскроешь, что такое llvm, осознаешь, что общего с jvm чуть более чем ничего.
>> Что до флеш, то он появился потому-что в браузерах на 6 лет
>> был тупо застой через монополию ie сформирован. Ну а сервилат вообще
>> был мёртворождённым.
>> Так что это не технологии того времени были современными, а застой технологический
>> породил этих выкидышей.
> Так на чем надо было писать-то, чтоб сейчас "админы с жавой в
> bmc проблем не имели"? Вариант переписать вот весь IE в хром
> в 2001 году - не предлагать.RFB уже был.
>[оверквотинг удален]
>>>>> пофиг, но если выбирать между ненаписанным кодом на крестах и вот
>>>>> работающем на жаве - выбор немножко так очевиден.
>>>> Себе открывай такие секреты, нормальным людям не всё равно. А толковый спец
>>>> понимает, что бесполезный расход памяти можно убрать и запросить выгоду за
>>>> профит выразить в повышении ему ЗП.
>>> Ох, закончите хелловрот на ассемблере переписывать - озолотитесь! А пока в вилларибо
>>> переписывают- в виллабаджо ява - от инфраструктуры до бизнес-логики - работает.
>> Ты басни не рассказывай, всякие хадупы, касандры и еластиксёрчи уже умерли -
>> спасибо за mvp, дальше им крематорий истории.
> Ah, irony...
> Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже разных вендоров и версий, распиханными по контейнерам.Ну так а зачем вы эникеев девопсами назначили? У моих почему-то вышло разобраться и как HPA настроить, и как выключать неиспользуемые серверы, и успевать включать их обратно при росте нагрузки на прод до того, как будет поздно. Попробуйте нанимать специалистов, которые разбираются в вопросе лучше чем вы.
>> Или devops'ам, которые в тихом а..уе от замеров расхода ОЗУ на серверах выделяемых и не используемых сотнями и тысячами поделиям на jvm, тоже разных вендоров и версий, распиханными по контейнерам.
> Ну так а зачем вы эникеев девопсами назначили? У моих почему-то вышло
> разобраться и как HPA настроить, и как выключать неиспользуемые серверы, и
> успевать включать их обратно при росте нагрузки на прод до того,
> как будет поздно. Попробуйте нанимать специалистов, которые разбираются в вопросе лучше
> чем вы.Со своими глупыми оценочными суждениями лучше разбирайтесь, т.к. явно не понимаете сути проблемы о блоках памяти выделенных jvm приложениями.
ты забыл самое главное - люцент и еластик который поверх него работает
это используется ну абсолютно везде
> ты забыл самое главное - люцент и еластик который поверх него работаети тормозят
> это используется ну абсолютно везде
нет
>Kafka, Cassandra, Hadoop, DynamoDbсовременные решения, интересно почему они на кладбище?
> миллионы мобильных приложений вообще молчуи эти миллионы приложений написанные на java выжирают батарею на мобилке. как думаешь почему огрызки не любят java
>Хорошо так стоит, даже не знаю, есть ли язык который близко бы встать смог
сча растаманы подтянутся
на 1 месте для написание хайлоад многопоточного энторпрайз кода
да все так
на втором шарп
Да, со времён j2me ничего удивительного не было уже.
java это язык программирования. А jvm это нИнужная нИнужность, от которой больше вреда чем пользы.
Ну ты сравнил, увиверсальную активно развивающуюся СУБД с кучей фичей, вылизанную для производительности, и устаревший ынтерпрайзный язык с кошмарным синтаксисом, никаким тулингом, без библиотеки модулей, без нормального GUI, с неэффективнейшим GC - можно перечислять бесконечно почему он не подходит ни для чего вообще.
А какой язык модный и молодежный, со всеми этими фичами?
>Релиз СУБД PostgreSQL 18Вот бы ещё 1С, в порядке заботы о национальной безопасности, добавила бы бескостыльную поддержку постгреса на уровне вражеских БД.
>поддержку постгреса
Пфф. Посгрес про как бы реестре.
Какой из? Их там много)
Платный энтерпрайз конечно лучше. Но есть отдельная и бесплатная PostgresPro-1C, он в репе которую легко прикрутить с топовым дистрибутивам как буржуйским так и нашим.
Да вы что...
> вражеских БДХочешь дружбы — будь другом. (с)
>Хочешь дружбы — будь другом. (с)С некоторыми, дружить слишком дорого.
Первые 2 ссылки в поиске вроде говорят о том, что все есть?https://1c.postgres.ru/
https://postgrespro.com/docs/postgrespro/16/config-one-c
Э. Там вроде кривые самопильные патчи, скомпонованные в отдельный "дистрибутив". В мейнлайне их нема
postgrespro - кривые самопильные патчи?
>Лицензия СУБД Postgres Pro Enterprise для 1C на 1 ядро x86-64, обновления 1 месяц
>108939 рублей
Не. Тот postgres что от 1с
Он бесплатен
И? Как это соотносится с "кривыми самопальными патчами" упакованными в отдельный дистрибутив?
Претензия была в том, что 1c с postgres НЕ РАБОТАЕТ - а работает вот с "postgres4OdinASS", которая "этадругое!". И если почему эту коллекцию не добавляют в mainline - понятно, то что мешает её успешно импортозаместить(ТМ) в основном продукте - вызвает вопросики.
Сто раз жевали уже.
"кривой самопальный" (весьма относительно кривой - просто приводит поведение _по_умолчанию_ к такому же как у mssql - потому что васяны-разработчики расширений разумеется ничего у себя починять не собирались) там ровно один.Все остальное - стандартные extensions стандартным способом, официально одобренным самими разработчиками postgres.
Тоже добавляют прозрачной совместимости с MS, без необходимости "vacuum analyze" вручную дергать.
(вот почему это 10 лет не хотят забирать к себе альтернативно-одаренные разработчики pgpro... а впрочем, понятно, они ж тогда станут ненужны)
С одной стороны, PostgreSQL имеет архитектурные ограничения из-за MVCC/VACUUM и отсутствия tempdb. С другой стороны, 1C активно использует UPDATE и временные таблицы, что при этих архитектурных ограничениях неэффективно.
Поэтому "бескостыльная поддержка постгреса на уровне вражеских БД", которые имеют undo-буфер и tempdb, невозможна без значительных изменениях в стандартных конфигурациях 1C или еще более значительных изменениях архитектуры PostgreSQL.
У меня сервера 1С с 13 года работают на Linux + Postgres. В чем проблема?
> У меня сервера 1С с 13 года работают на Linux + Postgres.
> В чем проблема?Я выше указал две проблемы. Во-первых, нагрузка на VACUUM из-за реализации MVCC в PostgreSQL и активном использовании UPDATE. Во-вторых, отсутствие tempdb и неумение стандартных конфигураций 1С воспользоваться pg_variables или нежурналируемыми таблицами.
> Во-первых, нагрузка на VACUUM из-за реализации MVCC в PostgreSQL и активном использовании UPDATE.И? В чем тут проблема? Это особенность работы бизнеслогики. Когда много пользователей активно пишут в одни и теже таблицы, без управляемых блокировок не обойтись.
> Во-вторых, отсутствие tempdb и неумение стандартных конфигураций 1С воспользоваться pg_variables или нежурналируемыми таблицами.
В 1С есть ещё очень много странного и спорного. Ты например, в курсе что таблицы значений, в отличии от дркгих коллекций, движок 1С располагает не в памяти, а на диске в папке с временными файлами и при каждом чтении из тз или записи в тз он обращается к диску, поэтому их не рекомендуют использовать без крайней необходимости. Хотя на это есть свои причины.
>> Во-первых, нагрузка на VACUUM из-за реализации MVCC в PostgreSQL и активном использовании UPDATE.
> И? В чем тут проблема? Это особенность работы бизнеслогики. Когда много пользователей
> активно пишут в одни и теже таблицы, без управляемых блокировок не
> обойтись.При чем тут управляемые блокировки и бизнес-логика? При помощи частичных индексов вполне можно избегать UPDATE, выполняя очистку старых версий периодическими заданиями в периоды низкой загрузки БД, а не средствами AUTOVACUUM.
А undo-буфер вполне эффективно решает проблему активного использование UPDATE.
> Когда использовать частичные индексы?
> Если вы часто запрашиваете только часть данных по определённому условию.
> Если таблица большая, а индексировать все строки неэффективно.
> Если условие фильтрации стабильно и не меняется часто.Ни один из этих случаев не подходит к 1С.
> Ни один из этих случаев не подходит к 1С.Замечательно подходит, если все версии записей в таблице, кроме последних, нужны только в целях аудиторского следа и периодическим заданием переносятся в архив.
> Замечательно подходит, если все версии записей в таблице, кроме последних, нужны только
> в целях аудиторского следа и периодическим заданием переносятся в архив.Причём тут вообще версии записей?
При том что такой подход позволяет избежать проблем, возникающих при модификации записей, когда не применим HOT-update.
> При том что такой подход позволяет избежать проблем, возникающих при модификации записей, когда не применим HOT-update.А с чего ты решил что там часто происходит модификация записей? Основное там это создание и реже удаление записей.
Я не решил, я вижу профиль нагрузки и то, как там шурует VACUUM после UPDATE. В первую очередь - по регистрам накопления и регистрам расчета, хотя регистры сведений и регистры бухгалтерии тоже активно модифицируются.
> Я не решил, я вижу профиль нагрузки и то, как там шурует VACUUM после UPDATE.Так он и шурует потому что при перепровденеии документа, у тебя все его записи в регистры сначала удаляются, а потом создаются по новой. Так что версионирование тут вообще не при делах. Все операции в 1С идут в транзакциях, в жестко заданной последовательности, сначала очистка всех существующих движений, а потом создание новых. Поэтому нельзя в движениях документа просто одну строчку подправить. Точнее отредактиовать набор движений можно с пмощью обработок, но это уже совсем не штатная ситуация.
>> Я не решил, я вижу профиль нагрузки и то, как там шурует VACUUM после UPDATE.
> Так он и шурует потому что при перепровденеии документа, у тебя все
> его записи в регистры сначала удаляются, а потом создаются по новой.MVCC в PostgreSQL именно так и устроено. Так как нет UNDO-буфера, то старые (модифицированные или удаленные) записи остаются в страницах БД до их зачистки VACUUM. Поэтому я и пишу, что можно существенно повысить производительнось БД при пиковой нагрузке не удаляя старые версии, а исключая их из последующих выборок. А уже зачистить их можно в периоды низкой загрузки.
> MVCC в PostgreSQL именно так и устроено. Так как нет UNDO-буфера, то
> старые (модифицированные или удаленные) записи остаются в страницах БД до их
> зачистки VACUUM. Поэтому я и пишу, что можно существенно повысить производительнось
> БД при пиковой нагрузке не удаляя старые версии, а исключая их
> из последующих выборок. А уже зачистить их можно в периоды низкой
> загрузки.У записи регистра в может только два состояния или она действующая или помечена на удаление автовакуумом. Помеченная на удаление запись и так не участвуе в выборках. История изменения регистров в 1С никак не хранится и не используется.
> У записи регистра в может только два состояния или она действующая или
> помечена на удаление автовакуумом.ДЛЯ AUTOVACUUM
> Помеченная на удаление запись и так не
> участвуе в выборках. История изменения регистров в 1С никак не хранится
> и не используется.Вот поэтому намного лучше зачищать эти записи не AUTOVACUUM в периоды пиковой нагрузки, а периодическим заданием в периоды низкой загрузки.
> ДЛЯ AUTOVACUUMТы мне все пытаешься доказать что 1С МОДИФИЦИРУЕТ записи регистров. А я тебе говорю НЕ МОДИФИЦИРУЕТ, а УДАЛЯЕТ и СОЗДАЕТ новые. Она САМА это делает, сначала таблица движений очищается, а потом заполняется заново. Версионирование в 1С есть но оно работает опять же средствами платформы а не СУБД, и не касается регистров и движений документов. Я тебе поэтому и сказал изначально что тут все дело в бизнеслогике, а не в Postgres. И частичные индексы тут никак не помогут.
> Вот поэтому намного лучше зачищать эти записи не AUTOVACUUM в периоды пиковой
> нагрузки, а периодическим заданием в периоды низкой загрузки.AVTOVACUUM и так запускается только в приоды низкой нагрузки. И ты его можешь элементарно отключить и создать регламентное задание для запуска сам, когда тебе больше нравится.
>> ДЛЯ AUTOVACUUM
> Ты мне все пытаешься доказать что 1С МОДИФИЦИРУЕТ записи регистров. А я
> тебе говорю НЕ МОДИФИЦИРУЕТ, а УДАЛЯЕТ и СОЗДАЕТ новые.С точки зрения реализации MVCC в PostgreSQL это ОДНО И ТО ЖЕ!
> сначала таблица движений очищаетсяА вот как раз этого делать в PostgreSQL не стоит, так как вызовет автоматически нагузку от AUTOVACUUM вскоре после завершения транзакции.
>> Вот поэтому намного лучше зачищать эти записи не AUTOVACUUM в периоды пиковой
>> нагрузки, а периодическим заданием в периоды низкой загрузки.
> AVTOVACUUM и так запускается только в приоды низкой нагрузки.Он пытается это делать, но с переменным успехом
> И ты его
> можешь элементарно отключить и создать регламентное задание для запуска сам, когда
> тебе больше нравится.AUTOVACUUM не только старые записи зачищает. Тогда потребуется всё равно вручную гонять ANALYZE для обновления статистик и опять же VACUUM для обновления карт видимости и защиты старых данных от transaction ID wraparound и multixact ID wraparound.
> С точки зрения реализации MVCC в PostgreSQL это ОДНО И ТО ЖЕ!Нет, не одно и то же. 1С не позволяет двум пользователям одновременно редактировать один и тот же документ. Это прямо запрещено платформой. Поэтому MVCC ту не при делах. А вот управляемые блокировки очень даже нужны, потому что два и больше пользователей могут одновременно редавктировать и записывать разные документы одного вида, которые будут писать в одни и те же регистры и что бы при записи не возникало конфликтов блокировок блокировка происходит по нужным полям. MS SQL это делает автоматически, поэтому 1С до 8.3 не умела в ручные блокировки, теперь весь код штатных конфигураций уже давно переписан под ручные блокирвки.
> А вот как раз этого делать в PostgreSQL не стоит, так как вызовет автоматически нагузку от AUTOVACUUM вскоре после завершения транзакции.
А без этого можешь получить очень тяжело отлавливаемые ошибки в бизнеслогике, которая всегда расчитана на атомарность операций проведения и отмены проведения.
> AUTOVACUUM не только старые записи зачищает. Тогда потребуется всё равно вручную гонять ANALYZE для обновления статистик и опять же VACUUM для обновления карт видимости и защиты старых данных от transaction ID wraparound и multixact ID wraparound.
Тебе шашечки или ехать? Ты или полагаешься на уже готовые механизмы которые в большинстве случаев всетаки работают как надо, или делаешь все сам.
>> С точки зрения реализации MVCC в PostgreSQL это ОДНО И ТО ЖЕ!
> Нет, не одно и то же.Проверьте сами INSERT и DELETE записи в одной транзации и UPDATE. Будете сильно удивлениы тем, что в страницах таблицы в обоих случаях увидите одно и то же )))
>> А вот как раз этого делать в PostgreSQL не стоит, так как вызовет автоматически нагузку от AUTOVACUUM вскоре после завершения транзакции.
> А без этого можешь получить очень тяжело отлавливаемые ошибки в бизнеслогике, которая
> всегда расчитана на атомарность операций проведения и отмены проведения.А с чего Вы решили, что при этом будет нарушаться ACID? )))
> Тебе шашечки или ехать? Ты или полагаешься на уже готовые механизмы которые
> в большинстве случаев всетаки работают как надо, или делаешь все сам.Вот именно. Если готовый механизм имеет какие-то недостатки и для меня они критичны, то я делаю сам. И пока в PostgreSQL не появится дополнительная система хранения с undo-буфером, другого выбора нет.
> А с чего Вы решили, что при этом будет нарушаться ACID? )))Измененный документ вообще не факт что будет писать в регистр в котором были его движения до изменения. Все это надо отслеживать и грозит сложно отлавливаесыми логическими ошибками. Поэтому правило одно, перед проведением таблица движений документа дожна быть пуста. Поэтому все твои претензии не имеют смысла в отношении 1С.
К сложным проверкам во время транзакции проведения 1С вообще настроена не очень. Дешевле провести документ закрыть транзакцию без проверок, запросить нужные показатели итогов и если что-то пошло не так отменить проведение очистить движения. Так часто делается в типовых конфигурациях. Главная цель актуальность итогов
>> А с чего Вы решили, что при этом будет нарушаться ACID? )))
> Измененный документ вообще не факт что будет писать в регистр в котором
> были его движения до изменения. Все это надо отслеживать и грозит
> сложно отлавливаесыми логическими ошибками.Сожалею, что Вы не способным мыслить иными категориями, чем сейчас заложено в 1С. В подавляющем большинстве ERP систем документ вообще нельзя изменить. Можно только ввести к нему корректирующий документ. В частном случае - аннулирующий. И никаких логических ошибок при этом не возникает.
Заодно не возникает проблем и с особенностями MVCC PostgreSQL. Иными словами - то о чем я Вам пишу, десятилетиями проверенное и обкатанное решение.
> Сожалею, что Вы не способным мыслить иными категориями, чем сейчас заложено в 1С. В подавляющем большинстве ERP систем документ вообще нельзя изменить. Можно только ввести к нему корректирующий документ. В частном случае - аннулирующий. И никаких логических ошибок при этом не возникает.Если в 1С все делать правильно, а писать согласно методическим рекомендациям, то тут тоже не будет никаких логических ошибок.
Или есть ещё такая бесплатная открытая платформа из Белоруссии LSFusion, тоже использует Postgres. Там в табличной части одного документа может работать сколько угодно пользователей одновременно и все изменения будут динамически отображаться и на экране и в итогах. У всех свои подходы которые берутся не на пустом месте.
И невозможность отмены проведения документа далеко не всегда гарантирует отсутствие логических ошибок.
>> Сожалею, что Вы не способным мыслить иными категориями, чем сейчас заложено в 1С. В подавляющем большинстве ERP систем документ вообще нельзя изменить. Можно только ввести к нему корректирующий документ. В частном случае - аннулирующий. И никаких логических ошибок при этом не возникает.
> Если в 1С все делать правильно, а писать согласно методическим рекомендациям, то
> тут тоже не будет никаких логических ошибок.При чем тут это? Для пользователя подход неизменности документов может быт вообще прозрачен.
> И невозможность отмены проведения документа далеко не всегда гарантирует отсутствие логических
> ошибок.Вы так пытаетесь подменить тезис? Я вообще-то опровергал Ваше утверждение, что подход с неизменными документами приведет к логическим ошибкам. А вот подход с модификацией документа приводит к необходимости обеспечивать аудиторский след иными способами. И тут как раз для логических ошибок большой простор.
> При чем тут это? Для пользователя подход неизменности документов может быт вообще
> прозрачен.Запретить менять документы можно и в 1С. Технически это не проблема. А вот для пользователей это будет проблема.
> А вот подход с
> модификацией документа приводит к необходимости обеспечивать аудиторский след иными способами.Но предположение что это делается с помошью MVCC абсолютно не верно.
> И тут как раз для логических ошибок большой простор.
Но зато удобнее, особенно для маленьких контор.
> А вот для пользователей это будет проблема.А Вы читайте иногда, на что отвечаете:
>> Для пользователя подход неизменности документов может быть вообще прозрачен.Совсем другой вопрос, что если в SAP или OEBS этот подход предоставляется в ряде случаев "из коробки", то в 1C его можно встретить только в кастомных конфигурациях.
> Но предположение что это делается с помошью MVCC абсолютно не верно.
Я готов не предполагать, а утверждать, что любые модификации БД в PostgreSQL сейчас реализуются с использованием MVCC. Иного там просто не дано )))
>> И тут как раз для логических ошибок большой простор.
> Но зато удобнее, особенно для маленьких контор.Чем удобнее? Восстанавливать историю изменений документов по аудиторскому журналу, вместо того, чтобы видеть это явно? Это уже на извращение тянет )))
> Совсем другой вопрос, что если в SAP или OEBS этот подход предоставляется
> в ряде случаев "из коробки", то в 1C его можно встретить
> только в кастомных конфигурациях.Напомню 1С Предприятие это платформа на которой работают самые разные конфигурации. Ты сейчас сравниваешь готовое решение с платформой?
> Я готов не предполагать, а утверждать, что любые модификации БД в PostgreSQL
> сейчас реализуются с использованием MVCC. Иного там просто не дано )))Давая я напомню что ты писал ранее, видать уже подзабыл
> Замечательно подходит, если все версии записей в таблице, кроме последних, нужны только в целях аудиторского следа и периодическим заданием переносятся в архив.
В случае с 1С все версии записей кроме последних "помечены на удаление" и не участвую в выборке и индексах и периодическим заданем удалаяются из базы на совсем.
> Чем удобнее? Восстанавливать историю изменений документов по аудиторскому журналу, вместо
> того, чтобы видеть это явно? Это уже на извращение тянет )))Там всем в большинстве случаев пофиг что было в документе до исправления, а если не пофиг, то есть специальный механизм версионирования, который работает средствами платформы, версии документов сохраняются в отдельные таблицы.
А делать любые исправления документами сторнирования будет очень неудобно особенно если организация это маленький розничный магазинчик где работает 3 человека.
>> Совсем другой вопрос, что если в SAP или OEBS этот подход предоставляется
>> в ряде случаев "из коробки", то в 1C его можно встретить
>> только в кастомных конфигурациях.
> Ты сейчас сравниваешь готовое решение с платформой?Прочитайте, что я написал:
>> Для пользователя подход неизменности документов может быть вообще прозрачен.
> В случае с 1С все версии записей кроме последних "помечены на удаление"
> и не участвую в выборке и индексах и периодическим заданем удалаяются
> из базы на совсем.Если бы. Как раз наоборот, в подавляющем большинстве конфигураций записи удаляются в БД, а не "помечаются на удаление".
> Там всем в большинстве случаев пофиг что было в документе до исправления
Большинству бомжей на вокзале? Бухгалтеру не всё равно, так как именно ему нужно объяснять, почему во вчерашнем и сегодняшнем отчетах показатели разные. Управленцу, по тем же причинам - тоже. Разработчику - тем более. Так кому еще всё равно?
> А делать любые исправления документами сторнирования будет очень неудобно особенно если
> организация это маленький розничный магазинчик где работает 3 человека.Неудобно, что БД вместо 100МБ будет 150МБ? Или что неудобно? )))
> Если бы. Как раз наоборот, в подавляющем большинстве конфигураций записи удаляются в БД, а не "помечаются на удаление".Ты опять путаешься в своих показаниях.
> Большинству бомжей на вокзале?
Подавляющее большинство фирм, это как раз те самый "бомжи" где есть "управленец" он же "грузчик/работник" и пара-тройка нанятых работяг. И даже в конторах покрупнее ситауция будет плюс/минус такая же. Ты думаешь диркетору очень интересно забивать сторнирующие документы на каждый чих.
> Неудобно, что БД вместо 100МБ будет 150МБ? Или что неудобно? )))
Ты размеры баз 1С давно видел?
>> Если бы. Как раз наоборот, в подавляющем большинстве конфигураций записи удаляются в БД, а не "помечаются на удаление".
> Ты опять путаешься в своих показаниях.Процитируйте.
>> Большинству бомжей на вокзале?
> Подавляющее большинство фирм, это как раз те самый "бомжи" где есть "управленец"И ему не нужно никому объяснять, почему вчера в отчете этот показатель был один, а сегодня стал другой? )))
> Ты думаешь диркетору очень интересно
> забивать сторнирующие документы на каждый чих.Вы принципиально не читаете сообщения, на которые отвечаете?
>> Для пользователя подход неизменности документов может быть вообще прозрачен.
>> Неудобно, что БД вместо 100МБ будет 150МБ? Или что неудобно? )))
> Ты размеры баз 1С давно видел?Если речь про УСН и "маленький розничный магазинчик где работает 3 человека" - то вполне адекватная оценка.
> ПроцитируйтеДва тут всю ветку цитировать. Я тебе в сотый раз говорю 1С не использует предыдущие версии записей в таблицах. Они сразу идут под нож. Поэтому частичные индексы тут не актуальны.
> И ему не нужно никому объяснять, почему вчера в отчете этот показатель был один, а сегодня стал другой? )))
А то он этого не помнит.
> Для пользователя подход неизменности документов может быть вообще прозрачен.
Можно хоть один реальный пример такой "прозрачности"?
> Если речь про УСН и "маленький розничный магазинчик где работает 3 человека" - то вполне адекватная оценка.
Нолик добавь в конце.
>> Процитируйте
> Два тут всю ветку цитировать. Я тебе в сотый раз говорю 1С
> не использует предыдущие версии записей в таблицах. Они сразу идут под
> нож. Поэтому частичные индексы тут не актуальны.А я уже в сотый раз говорю, что не платформа 1С, а некоторые конфигурации 1С, в том числе почти все типовые. И это и есть проблема при работе с PostgreSQL и его реализации MVCC.
>> И ему не нужно никому объяснять, почему вчера в отчете этот показатель был один, а сегодня стал другой? )))
> А то он этого не помнит.Так три работника плюс владелец или один ИП? )))
>> Для пользователя подход неизменности документов может быть вообще прозрачен.
> Можно хоть один реальный пример такой "прозрачности"?WM в SAP. Несмотря на то, что пользователь вроде бы редактирует документы, в БД сохраняется вся история. В отчетах можно выводить как в свернутом виде, так и в виде всех изменений. Вся логика подобна GIT. Даже операции называются CheckIn и CheckOut.
Если речь о кастомных конфигурациях 1С, то тоже самое реализовано, например, на ММК.>> Если речь про УСН и "маленький розничный магазинчик где работает 3 человека" - то вполне адекватная оценка.
> Нолик добавь в конце.Если склад и номенклатура не ведется, а заводятся только доходы в виде одной строки на накладную и расходы, в виде кассы за день - именно такая БД и будет. На диске, само собой добавится сотня-другая мегабайт самой конфигурации. Но мы же говорим о размере PostgreSQL БД. Это же не MS SQL, где сразу несколько гигабайт на БД выделяется на диске )))
> А я уже в сотый раз говорю, что не платформа 1С, а некоторые конфигурации 1С, в том числе почти все типовые. И это и есть проблема при работе с PostgreSQL и его реализации MVCC.Конфигурации никак не могут повлиять на то как данные пишутся. Запросы в 1С могут только читать. А пишутся данные методами соответствующих объектов. И объект может быть записан только целиком.
> Так три работника плюс владелец или один ИП? )))
Ты мне сейчас решил рассказать как у нас работает малый бизнес?
> WM в SAP. Несмотря на то, что пользователь вроде бы редактирует документы, в БД сохраняется вся история.
Никакого кастома, самая что ни на есть стандартная конфигурация
> Если склад и номенклатура не ведется, а заводятся только доходы в виде одной строки на накладную и расходы, в виде кассы за день - именно такая БД и будет. На диске, само собой добавится сотня-другая мегабайт самой конфигурации. Но мы же говорим о размере PostgreSQL БД. Это же не MS SQL, где сразу несколько гигабайт на БД выделяется на диске )))
Мы не в европе что бы учет в экселе вести. Все больше и больше позиций товаров попадает под обязательную маркировку честного знака. Приход через ЭДО, продажа через кассу или тот же ЭДО. Каждая марка проверяется в общей системе.
> Конфигурации никак не могут повлиять на то как данные пишутся. Запросы в
> 1С могут только читать.А ребята то не знали и сплошь и рядом модифицируют БД через кастомные таблицы регистрации и планы обмена )))
Я уже молчу о модификации БД через SQL.>> Так три работника плюс владелец или один ИП? )))
> Ты мне сейчас решил рассказать как у нас работает малый бизнес?Не вижу ответа на вопрос.
> Все больше
> и больше позиций товаров попадает под обязательную маркировку честного знака.У ИП торгующего песком, щебнем, землёй и навозом в розницу? )))
> А ребята то не знали и сплошь и рядом модифицируют БД через кастомные таблицы регистрации и планы обмена )))Ты хотябы представляешь что такое план обмена? Грубо говоря это механизм который регистрирует изменения объектов и формирует сообщения для обмена содержащие зарегистрированные объекты. А сообщения, по-твоему, кто в итоге пишет в базу? Да сообщения пишутся в режиме обмена, но это значит что они пишутся минуя стандартные проверки. Но пишутся они все теми же средствами встроенными в эти объекты. То есть если тебе пришло 10 документов, для каждого документа вызывается метод записать, и он пишет объект без вызова процедур проверки перед и при записи. Так что ещё раз повторяю в 1С всегда будет использоваться объектная запись в базу средствами платформы, никаких прямых запросов.
> Я уже молчу о модификации БД через SQL.
Это уже про попытки починить какие-то поломки или очень нестандартные операции, потому что зачастую это коцает базу. Я, например, так чистил базу которая занимала около 50 гигов от документов, просто через консоль sql дропаешь таблицы с документами, а потом через тестирование и исправление удаляешь битые ссылки, все занимает паручасов. Иначе обычное удаление документов из базы такого размера заняло бы несколько дней.
> Не вижу ответа на вопрос.
Какой тебе ответ на вопрос? Я тебе скрин скинул. Или это слишком сложно для понимания?
> У ИП торгующего песком, щебнем, землёй и навозом в розницу? )))
А ИП торгующий например товарами для рыбалки? Там в маленьком магазинчике спокойно может быть нескольлко тысяч наименований. Плюс маркированная одежда и обувь.
>> А ребята то не знали и сплошь и рядом модифицируют БД через кастомные таблицы регистрации и планы обмена )))
> Ты хотябы представляешь что такое план обмена?Естественно. План обмена позволяет вести в SQL БД любые кастомные таблицы как душе угодно.
>> Я уже молчу о модификации БД через SQL.
> Это уже про попытки починить какие-то поломки или очень нестандартные операции, потому
> что зачастую это коцает базу. Я, например, так чистил базу которая
> занимала около 50 гигов от документов50ГБ как раз слишком мелкая БД, чтобы стоило напрягаться через SQL. Вот когда БД больше терабайта, тогда уже без SQL не обойтись.
>> Не вижу ответа на вопрос.
> Какой тебе ответ на вопрос? Я тебе скрин скинул. Или это слишком
> сложно для понимания?Мне нужен ответ.
>> Так три работника плюс владелец или один ИП? )))
>> У ИП торгующего песком, щебнем, землёй и навозом в розницу? )))
> А ИП торгующий например товарами для рыбалки? Там в маленьком магазинчике спокойно
> может быть нескольлко тысяч наименований. Плюс маркированная одежда и обувь.А почему Вы придумываете, какой именно вид бизнеса ИП я имел ввиду, указывая размер БД в 100-150МБ? )))
> Естественно. План обмена позволяет вести в SQL БД любые кастомные таблицы как душе угодно.Бред. Если тебе это сказали твои друзья 1С-ники, то они мягко говоря не понимают о чем говорят. В 1С записать что-то можно только методом соответсвующего объекта.
> 50ГБ как раз слишком мелкая БД, чтобы стоило напрягаться через SQL. Вот когда БД больше терабайта, тогда уже без SQL не обойтись.
А ты попробуй удалить.
> Мне нужен ответ.
Я показал тебе скрин, если ты не понял о чем это то какой смысл спорить?
> А почему Вы придумываете, какой именно вид бизнеса ИП я имел ввиду, указывая размер БД в 100-150МБ? )))
Потому что даже пустая база 1С сейчас весит около гига. Если конечно это не база без конфигурации.
Какой смысл спорить о том в чем ты не понимаешь?
>> Естественно. План обмена позволяет вести в SQL БД любые кастомные таблицы как душе угодно.
> Бред.Уже радует, что Вам приходится в технической дискуссии прибегать к эмоциональным оценкам )))
> В 1С записать что-то можно только методом соответсвующего объекта.
А в кастомные таблицы SQL БД можно и через план обмена. При этом читать оттуда можно напрямую SQL запросами.
>> 50ГБ как раз слишком мелкая БД, чтобы стоило напрягаться через SQL. Вот когда БД больше терабайта, тогда уже без SQL не обойтись.
> А ты попробуй удалить.У меня таблички есть, содержащие более миллиарда записей. И ничего, живу как то )
>> Мне нужен ответ.
> Я показал тебе скрин, если ты не понял о чем это то
> какой смысл спорить?То есть, ответ дать не можете? Фиксируем.
>> А почему Вы придумываете, какой именно вид бизнеса ИП я имел ввиду, указывая размер БД в 100-150МБ? )))
> Потому что даже пустая база 1С сейчас весит около гига. Если конечно
> это не база без конфигурации.Во-первых, смотря какой конфигурации. Во-вторых, даже типовую конфигурация несложно почистить от ненужного функционала. В-третьих, не сравнивайте размеры БД в MS SQL и PostgreSQL. Это очень разные вещи.
> Уже радует, что Вам приходится в технической дискуссии прибегать к эмоциональным оценкам )))Когда в технической дискуссии несут бред, я это так и называю.
> А в кастомные таблицы SQL БД можно и через план обмена. При этом читать оттуда можно напрямую SQL запросами.
Ну ты же сможешь привести код котоорый это делает?
> У меня таблички есть, содержащие более миллиарда записей. И ничего, живу как то )
Удалить миллиард записей в sql и удалить миллион документов в 1С средствами платформы, это очень разные вещи.
> То есть, ответ дать не можете? Фиксируем.
Фиксируем что ты ниразу не видел 1С.
> Во-первых, смотря какой конфигурации. Во-вторых, даже типовую конфигурация несложно почистить от ненужного функционала.
Можно без в-третьих. Только очень "одаренный специалист" полезет удалять что-то из типовой.
>> Уже радует, что Вам приходится в технической дискуссии прибегать к эмоциональным оценкам )))
> Когда в технической дискуссии несут бред, я это так и называю.Ну раз настаиваете, то мне остается только принять Ваше поражение в дискуссии. Мне нужды переходить на личности нет.
> Ну раз настаиваете, то мне остается только принять Ваше поражение в дискуссии.
> Мне нужды переходить на личности нет.Слился, "специалист". Вместо того что бы показать код, жалуемся на "оскорбления".
Что является диском, а что является памятью это вопрос, как ты сервак настроишь-)) Так, что никто не мешает временные файлы отправить в память, точно также, как интересующие тебя каталоги, а софт будет считать, что он данные с диска читает/пишет-)
> Что является диском, а что является памятью это вопрос, как ты сервак
> настроишь-)) Так, что никто не мешает временные файлы отправить в память,
> точно также, как интересующие тебя каталоги, а софт будет считать, что
> он данные с диска читает/пишет-)В определенных случаях у тебя есть вероятность того что память закончится и сервак придется перезапускать. Они не просто так тз засунули на диск.
Вот по какой то причине, когда возникает вопрос работоспособности 1C на Postgres, все почему то начинают рассказывать, что именно не так с Postgres! Так вот ребятушки, с Postgres все так и нет ни каких проблем. Они состоявшаяся db, которая выполняет свои задачи и успешно развивается так, как считает необходимым.А вот с 1C все не так весело т.к без БД она бесполезна от слова совсем. Беда в том, что занимая практически монопольную долю рынка Бух софта в РФ, 1С делает свою зависимость от MSSQL, зависимостью практически всех российских предприятий от иностранного поставщика. И народ ещё удивляется, куда и как утекают их данные.
1С 20 лет не может написать драйвер для работы с Postgres! И это при том, что народ и прокси писал, и что только не колхозил. В текущих реалиях - это просто диверсия.
> 1С 20 лет не может написать драйвер для работы с Postgres!Потому что проблема не в драйвере, а в коде стандартных конфигураций. Не сложно написать кастомный код, который будет работать с PostgreSQL эффективно. Сложно переписать уже имеющиеся конфигурации.
>Потому что проблема не в драйвере, а в коде стандартных конфигураций.Я думаю, что за 20 лет можно было переписать все с 0 несколько раз.
Более того, это практически было сделано 77->80->81->82->83. Да, это платформы, но конфигурации при переходи с 77 тоже требовали конвертации. При этом в плане поддержки постгреса было сделано только прекращение публикации оффицальных патчей!Видимо Микрософт просто каждый год поздравляет руководство 1С с днем рождения :)
> Я думаю, что за 20 лет можно было переписать все с 0Еще три года назад MS SQL был сертифицирован ФСТЭК и особой нужды всё переписывать не было.
А так как такое переписывание, по сути, обозначает отказ от регистров в их текущем виде, то переписывать действительно надо всё.
Где это было прекращена публикация патча? Зашел на https://releases.1c.ru/total и вот он, родимый, в общей куче с исходниками и криво собранными пакетами.
Да-да, и вот окромя 1с - никого в индустрии vacuum не напрягает, да?
Тут, пардону прошу, оба-два хороши (Но 1с, кнешн сильно "лучше")
Более того в том или ином виде vacuum есть и в MS SQL и в MY SQL
> У меня сервера 1С с 13 года работают на Linux + Postgres.
> В чем проблема?Ну, предполагаю в том, что вообще без бэдэ - файликами на диске - работало бы быстрее ).
Нет, без внешней БД, будет использоваться внутренняя, а она, особенно при работе по сети, будет работать очень медленно. Ты времена 7.7 забудь сейчас 1С даже близко не похожа на то что было тогда.
> Нет, без внешней БД, будет использоваться внутренняя, а она, особенно при работе
> по сети, будет работать очень медленно. Ты времена 7.7 забудь сейчас
> 1С даже близко не похожа на то что было тогда.Так подключись через RDP и летай - двум иванам хватит.
> Так подключись через RDP и летай - двум иванам хватит.Ты до сих пор живёшь во времена 7.7? В файловом варианте для каждого клиента подключённого к базе эмулируется вся трехзвенка. Это медленно, имеете много накладных расходов, и черевато блокировками при активной работе.
>> Так подключись через RDP и летай - двум иванам хватит.
> Ты до сих пор живёшь во времена 7.7? В файловом варианте для
> каждого клиента подключённого к базе эмулируется вся трехзвенка. Это медленно, имеете
> много накладных расходов, и черевато блокировками при активной работе.Если в 13м году у тебя 1с работала на linux с postgres - с тем же успехом она могла (не) работать и в файловом варианте - только немножко быстрее ).
> Если в 13м году у тебя 1с работала на linux с postgres - с тем же успехом она могла (не) работать и в файловом варианте - только немножко быстрее ).Нет. 8.3 вышла в 12 году, Бухгалтерия 3.0 на управляемых формах в 13 году. Конфигурации на управляемых формах плохо работают в файловом режиме особенно на несколько пользователей. Так что там без альтернативно было только на серваке.
Это было бы возможно только при отказе от MSSQL и Оракла, ибо движок для работы с субд в нём максимально унифицированный.
Но как я посмел такое подумать, если даже в самых свежих конфигурациях от 1С все еще есть функционал "скачать видео с youtube" ))
Чего не хватает Постгресу, чтобы победить оракл? Ну кроме тех поддержки, конечно.
Multimaster
Неинклюзивно ты говоришь, дядя Фёдор. Надо Multimain или Multiprimary.
Тонко)
Это как единорог - его не существует
Ну вот сделали его в postgres pro - как, много ораклов напоебдяли?
И какой именно? Синхронный, который гарантированно тормозит или асинхронный, который гарантированно, хоть и не сразу потеряет консистентность через конфликты?
> Чего не хватаетМозгов не хватает программистам, чтобы просто взять и начать использовать.
На мой взгляд, не хватает только альтернативного, на выбор разработчика, движка хранения с undo-буфером и поддержки tempdb, чтобы DDL операции с временными таблицами не затрагивали information schema постоянных объектов БД. Остальное так или иначе решаемо, хоть и требует больше усилий при оптимизации запросов или реализации multimaster, чем в Oracle.
Ну, мне вот без пакетов ораклевых печальненько было поначалу. На кривой козе объезжать научился - но то прям такое.
> Ну, мне вот без пакетов ораклевых печальненько было поначалу. На кривой козе
> объезжать научился - но то прям такое.Это именно то, что хотя и несколько увеличивает нагрузку на разработчика, но имеет варианты решений. Кто-то расширениями от PostgesPro пользуется, кто-то реализует пакеты на схемах.
В любом случае, это не то, что действительно мешает переходу с Oracle на PostgreSQL.
Для начала, стать полноценной коммерческой СУБД, разработанной профессионалами. Нельзя строить серьёзный бизнес на "базе от Васяна", который вообще сантехник, а в свободное время опенсорсой балуется.
> Для начала, стать полноценной коммерческой СУБД, разработанной профессионалами. Нельзя
> строить серьёзный бизнес на "базе от Васяна", который вообще сантехник, а
> в свободное время опенсорсой балуется.В смысле, тоже в бангалор разработку перенести? Ну вот вам - в диапазоне от enterprise db\postgres pro до зеленых сливов, цитусов и прочих таймскалей, охапками - одна другой более "коммерческая"...
Direct IO, flasback database, data compression, encryption on the fly (здесь не уверен, надо проверять), undo tablespace, temp tablespace, real application cluster, autonomous transactions (обходится костылями), вменяемый экспорт/импорт (с возможностью на лету менять пользователей, исключать определённые объекты и т. д.), возможность синхронизации отставшей standby базы данных без файлов журнала регистрации транзакций, и много чего другого, что на ходу не вспомню.В общем, если у вас серьёзный бизнес и при этом в штате есть системные программисты - можно обойтись Postgres SQL, если системных программистов нет - Oracle СУБД на порядок удобней для энтерпрайз решений.
Вы накидали от балды все, что попалось под руку из поисковика, даже не посмотрев что есьт, и чего нет в PG. Ну и да, без рукоположенного авторизированными сектантами DBA и без регулярного заноса десятины в центральную церковь вы на все перечисленные вкусности Oracle можете только слюни пускать, будь вы хоть пятижды Ынтерпрайз.
Ну ок. Серьёзная, ЭНТЕРПНАЙЗНАЯ db. Какую из реализаций кластера можно считать референсной? Patroni, stolon, pacemaker+corosync, pgaf, biha? А что и как к этой "референсной" прикручивать для реализации резервного копирования так, чтобы для восстановления одной базы рядом отдельный сервак не поднимать? Нет, pg_dump - не предлагать, он вообще никоим образом не "backup". А уж maintenance нагруженной базы в этом кластере - прям отдельное удовольствие. Тут бы и "рукоположился", и даже может быть десятину занес - да особо некуда.
> Ну ок. Серьёзная, ЭНТЕРПНАЙЗНАЯ db. Какую из реализаций кластера можно считать референсной?Нет там референсной реализации. В зависимости от задач либо выбираешь наиболее подходящую, либо вообще делаешь свою.
В отличии от Oracle или MS SQL нет тут единой инфраструктуры от поставщика. Собирай сам, из того, что больше подходит. Может Вам больше Patroni подойдет. А может быть нужен Greenplum или YDB
>> Ну ок. Серьёзная, ЭНТЕРПНАЙЗНАЯ db. Какую из реализаций кластера можно считать референсной?
> Нет там референсной реализации. В зависимости от задач либо выбираешь наиболее подходящую,
> либо вообще делаешь свою.
> В отличии от Oracle или MS SQL нет тут единой инфраструктуры от
> поставщика. Собирай сам, из того, что больше подходит. Может Вам больше
> Patroni подойдет. А может быть нужен Greenplum или YDBТак я именно что про это. "Вот вам Самый ЛуДший В Мире Кардан, каку хотите машину вокруг него сами собирайте - а про "ехать" у нас с вами разговора вообще не было"(ТМ).
В этом плане postgres pro - у которого эта самая "референсная" с "единой инфрой от поставщика" в виде biha + pg_probackup - вполне даже и неплохо смотрится.
> В этом плане postgres pro - у которого эта самая "референсная" с
> "единой инфрой от поставщика" в виде biha + pg_probackup - вполне
> даже и неплохо смотрится.Так про то и речь, что сам ванильный PostgreSQL - это только СУБД, а вовсе не вся инфраструктура. Хотите инфраструктуру "из коробки" - используйте PostgresPRO, YDB, EDB, Greenplum и т.п. Вот там будут референсные решения от конкретного поставщика. Но при этом они будут сделаны всё равно на базе ванильного PostgreSQL и этого не отнять.
Иными словами, в отличии от MS SQL и Oracle у Вас есть выбор решения для инфраструктуры. А уже когда это хорошо, а когда это плохо - вопрос отдельный. Как по мне, выбор всегда лучше, чем его отсутствие.
>[оверквотинг удален]
>> даже и неплохо смотрится.
> Так про то и речь, что сам ванильный PostgreSQL - это только
> СУБД, а вовсе не вся инфраструктура. Хотите инфраструктуру "из коробки" -
> используйте PostgresPRO, YDB, EDB, Greenplum и т.п. Вот там будут референсные
> решения от конкретного поставщика. Но при этом они будут сделаны всё
> равно на базе ванильного PostgreSQL и этого не отнять.
> Иными словами, в отличии от MS SQL и Oracle у Вас есть
> выбор решения для инфраструктуры. А уже когда это хорошо, а когда
> это плохо - вопрос отдельный. Как по мне, выбор всегда лучше,
> чем его отсутствие.Ну это в общем-то и есть ответ на вопрос "Чего не хватает Постгресу, чтобы победить оракл?" - того же, чего не хватает "linux-это-ядру"(ТМ), чтобы победить windows )))
> Ну это в общем-то и есть ответ на вопрос "Чего не хватает
> Постгресу, чтобы победить оракл?"Как видим, кроме того, что я указал выше - всё хватает, да еще и дополнительно есть выбор.
> - того же, чего не хватает "linux-это-ядру"(ТМ),
> чтобы победить windows )))Если на суперкопьютерах это уже свершившийся факт, то в серверной инфраструктуре - уже почти свершившийся факт. По крайней мере среди моих клиентов я не знаю ни одного, где серверов под Linux было бы меньше, чем под Windows.
Desktop - отдельная история. Так как конечному пользователю часто хочется получить всё "из коробки", не задумываясь о том, что и как ему следует слепить вместе для его конкретных нужд. Но обсуждаемый PostgreSQL явно к десктопным приложениям имеет весьма косвенное отношение.
Панимашь ли, если в аналогию, то Postgres и Linux - это железная рама, к которой кое-как приварены колеса, на раму установлен движок (может и даже мощный, но это навряд ли), от которого в разные стороны идет куча разных проволочек. И вот ты сидишь на всем на этом, стараясь не выпасть во время движения, и дергаешь за разные проволочки, подавая движку разные команды.А Oracle или Windows - это просто удобный Кадилак, где все по-человечески.
> Панимашь ли, если в аналогиюВот только по факту Windows видим в основном на десктопах, иногда на серверах и уже не видим на суперкомпьютерах, о чем я указал выше. Так что факты Вашу аналогию разрушают на корню )))
И да, аналогия верна только в том смысле, что на Кадилаках сотни тонн не перевозят, в отличии от куда менее комфортных Белазах и железнодорожных локомотивах )))
Ну да, ну да, PostgreSQL супротив Oracle DB "Белаз" только в твоих влажных мечтах. PostgreSQL супротив Oracle DB я уже написал - кустарно сваренная металлическая рама с приваренными колесами и движком от мопеда.Как бы будь реалистом, а не мечтателем.
> Ну да, ну да, PostgreSQL супротив Oracle DB "Белаз"При чем тут Oracle, если его никто в здравом уме под Windows ставить не будет?
А реальность такова, что среди суперкомпьютеров Windows больше нет. А среди серверов в ЦОД Windows встречается намного реже, чем Linux. Даже в Azure у MS. И это уже факт.
>> Ну это в общем-то и есть ответ на вопрос "Чего не хватает
>> Постгресу, чтобы победить оракл?"
> Как видим, кроме того, что я указал выше - всё хватает, да
> еще и дополнительно есть выбор.Резюмирую - ответ "не хватает" примерно "ВСЕГО", а вот вопрос чего "не хватает" enterprise db, postgres pro, greenplum и иже с ними - нуждается в отдельном анализе, который я проводить решительно не компетентен :).
>>> Ну это в общем-то и есть ответ на вопрос "Чего не хватает
>>> Постгресу, чтобы победить оракл?"
>> Как видим, кроме того, что я указал выше - всё хватает, да
>> еще и дополнительно есть выбор.
> Резюмирую - ответ "не хватает" примерно "ВСЕГО"Всё субъективно. Для меня отсутствие undo-буфер и tempdb - это два пункта. Вы это называете "всё". Если, конечно исключить, что из-за полного непонимания того, чем СУБД отличается от инфраструктуры, Вы начинаете сравнивать несравниваемое.
>>>> Ну это в общем-то и есть ответ на вопрос "Чего не хватает
>>>> Постгресу, чтобы победить оракл?"
>>> Как видим, кроме того, что я указал выше - всё хватает, да
>>> еще и дополнительно есть выбор.
>> Резюмирую - ответ "не хватает" примерно "ВСЕГО"
> Всё субъективно. Для меня отсутствие undo-буфер и tempdb - это два пункта.
> Вы это называете "всё". Если, конечно исключить, что из-за полного непонимания
> того, чем СУБД отличается от инфраструктуры, Вы начинаете сравнивать несравниваемое.Ну, мне как "техническому заказчику" "СУБД per se" нужна примерно низачем - мне нужно встраиваемое в инфраструктуру проекта поддерживаемое конечным заказчиком решение, обладающее набором характеристик.
> Ну, мне как "техническому заказчику" "СУБД per se" нужна примерно низачем -
> мне нужно встраиваемое в инфраструктуру проекта поддерживаемое конечным заказчиком решение,
> обладающее набором характеристик.Ну тогда непонятно, что Вы вообще делаете на opennet. Бесплатные open source продукты Вас по определению тогда не устроят. Не умеете сами - платите тем, кто из этих продуктов делает собственное инфраструктурное решение и его поддерживает.
>> Ну, мне как "техническому заказчику" "СУБД per se" нужна примерно низачем -
>> мне нужно встраиваемое в инфраструктуру проекта поддерживаемое конечным заказчиком решение,
>> обладающее набором характеристик.
> Ну тогда непонятно, что Вы вообще делаете на opennet. Бесплатные open source
> продукты Вас по определению тогда не устроят. Не умеете сами -
> платите тем, кто из этих продуктов делает собственное инфраструктурное решение и
> его поддерживает."И вот все у вас так"(С)
> Нет, pg_dump - не предлагатьа pg_basebackup?
>> Нет, pg_dump - не предлагать
> а pg_basebackup?А как он тебе в решении вот _этой_ проблемы поможет?
Вот pg_probackup таки да, умеет include\exclude DB из бэкапа и даже incremental restore - но работает оно мнэээ... не совсем так, как вы, скорее всего, думаете - и от необходимости поднимать отдельный сервак, ресторить туда, потом переносить в целевой кластер с помощью pg_dump - не избавляет. SLA всей процедуры в общем случае - весьма и весьма печальный.
>> Нет, pg_dump - не предлагать
> а pg_basebackup?Ну тогда уже всё же WAL-G.
Вопрос - Postgresql 18 (2025 г) уже достиг уровня производительности, удобства использования Oracle 9i (2001 г) или еще нет или это вообще фантастика?
> Вопрос - Postgresql 18 (2025 г) уже достиг уровня производительности, удобства использования
> Oracle 9i (2001 г) или еще нет или это вообще фантастика?Нет, конечно. Но это и невозможно. Таких фантастических задач ни у кого и нет.
Решения из коробки для мамкиных программистов и интеграторов. Постгрес предполагает определенную квалификацию разработчиков и DBA.Но надо ли оно опенсорс-проекту?
Эффективности оптимизатора запросов Оракла (это самое печальное). Но для такой куцей и разношёрстной команды разработки это недостижимо в принципе. А так, в общем-то, всего: нормальной системы рез. копирования, нормальной мультиарендности, ну а про рэк, авр и адвизоры просто промолчу.
А когда будит наш, отечественный аналог?
https://postgrespro.ru/products
https://postgrespro.ru/products/postgrespro/standard
>169570 ₽ублей
за 1 ядро
+ поддержка
а еще если кластера то 350т чтоли за ядро
в общем жесть
Я ошибся чутка
622 908 руб за 1 ядро
Ну, походи по базару - посмотри где дешевле. (Хинт - mssql стоит вот ровно столько же)
но к нему нет в комплекте настойчивого совета перезагружать раз в две недели и не забывать делать vacuum analize каждый день.
> но к нему нет в комплекте настойчивого совета перезагружать раз в две
> недели и не забывать делать vacuum analize каждый день.Есть. К тому же в МС до сих пор нет нормального MVCC. Их snapshot-режимы до сих пор для индексов используют эксклюзивные блокировки даже для чтения.
Инфраструктурно МС хуже ПГ, но оптимизатор у МС куда более развитый -- несравнимо хуже Оракла, но всё же до сих пор лучше ПГ.
да их там в реестре десяток наверно. Тантор например
Разработкой обвеса на PostпreSQL, называемую Тантор, вроде как руководит (или руководил) израильский гражданин , хорошо бы не шпион - но это навряд ли.
Аналог чего? PostgreSQL? Это путь в никуда - рожденный ползать летать не может.Из того, что заслуживает внимания и о ком что-то слышно - Yandex DataBase или сокращенно YDB (https://ydb.yandex.ru/ https://ydb.tech/) 2 в одном - OLTP + OLAP.
> В командах INSERT, UPDATE, DELETE и MERGE
> реализована возможность вывода прошлых (OLD)
> и текущих (CURRENT) значений в выражении RETURNINGКак давно я это ждал! Как минимум, с 12-ой версии.
а какие в insert могут быть OLD значения?
могут быть NULL например
> а какие в insert могут быть OLD значения?Если INSERT с ON CONFLICT DO UPDATE, то те, которые были до UPDATE или NULL, если такой записи не было.
>> а какие в insert могут быть OLD значения?
> Если INSERT с ON CONFLICT DO UPDATE, то те, которые были до
> UPDATE или NULL, если такой записи не было.ага, понятно, а если запись была но с с NULL?
>>> а какие в insert могут быть OLD значения?
>> Если INSERT с ON CONFLICT DO UPDATE, то те, которые были до
>> UPDATE или NULL, если такой записи не было.
> ага, понятно, а если запись была но с с NULL?То же самое. Но если записи не было, то xmax будет ноль, а если была - то не ноль.
Так там все просто, если INSERT, то колонка OLD пуская, если DELETE то пуская NEW. И все в таком роде
> Добавлена функция uuidv7()Ура!
В этой смешной базе "регистронезависимость" по-прежнему реализована тупо через "приведём всё к нижнему регистру"?
> В этой смешной базе "регистронезависимость" по-прежнему реализована тупо через "приведём
> всё к нижнему регистру"?Поддержка ICU появилась еще в 12-ой версии.
https://www.postgresql.org/docs/current/sql-createcollation....
Читаем про DETERMINISTIC
"еще в".
То есть аж в 2019м году после 25 лет разработки кто-то сподобился!(надеюсь хоть не патч от 1с скопипастить)
> То есть аж в 2019м году после 25 лет разработки кто-то сподобился!Да потому что в подавляющем большинстве применений это на фиг никому не надо было.
> (надеюсь хоть не патч от 1с скопипастить)
А разве 1C уже поддерживает ICU и UTF-8 без вручную применяемых костылей?
Скажем прямо: за каким якодзуном вообще нужна была регистрозависимость?! От неё что в файлах толку НИКАКОГО, что в базе. Ну создал ты таблицу HiredPerson, а запросил данные из hiredPERSON - это что, потенциально две разные таблицы?!Вся идиотия с регистрами в СЛУЖЕБНЫХ именах напупь не нужна.
Лучше один раз написать с правильным регистром и потом сравнивать байты, чем кипятить процессор лишними операциями, которых потребует регистронезависимость.
> Скажем прямо: за каким якодзуном вообще нужна была регистрозависимость?!Точно так же возникает вопрос в том, а зачем вообще нужна была независимость от регистра?
Могу подсказать, что корни этого следует искать на мэйнфремах и совместимости с IBM 704, которая, исторически, имела корни в ITA1/2, коде Бодо и даже коде Морзо, где строчных букв не было и в помине )))> Ну создал ты
> таблицу HiredPerson, а запросил данные из hiredPERSON - это что, потенциально
> две разные таблицы?!Именно так, две разные таблицы и два разных файла на всех современных файловых системах, за исключением NTFS, пытающейся сохранять совместимость с DOS. Впрочем, NTFS позволятет включить независимость от регистра командой "fsutil file setCaseSensitiveInfo", так как это необходимо для поддержки WSL и деваться тут уже некуда.
> за исключением NTFSне только
zfs, например, тоже имеет такую опцию
>> за исключением NTFS
> не только
> zfs, например, тоже имеет такую опциюВ отличии от NTFS, ZFS по умолчанию чувствительна к регистру. А так, даже EXT4 поддерживает casefold, если такое требуется для легаси из Windows.
В PostgreSQL появилась встроенная функция генерации UUIDv7 для первичных ключей
>В PostgreSQL появилась встроенная функция генерации UUIDv7 для первичных ключейв UUIDv7 хоть есть timestamp? то что было в монго с рождения ) (удаляйте, удаляйте)
да есть и че?
нативная поддержка генерации UUID v7 в MongoDB появилась в версии 5.1, выпущенной в ноябре 2022 года
окончательный rfc на uuidv7 вышел в 2024
Мне кажется вы не достаточно какашек накидали в сторону MariaDB, MySQL, SQLite.
> SQLiteА ему то что? Ему фиолетово до сабжа.
Я был уверен, что многостолбцовые индексы так и работали. А оно вон как оказывается.
может ты еще думол что для внешних ключей сразу генерится индекс для джойнов?
Вы думали, что в запрос автоматически добавлялось условие AND FirstFieldsInIndex IN (<all distinct values of FirstFieldsInIndex>)?
Или Вы о чем то другом?
Кому и зачем это всё надо в 2к25 году, когда весь веб захватили serverless и nosql решения?
https://ru.wikipedia.org/wiki/ACID
1. не весь веб
2. помимо веба есть жизнь
В готовящуюся к релизу Fedora 43 уже завезли.