На 50 минут видоса смотреть? А есть краткое резюме о чем вещает бородатый господин?

Меня пугает слово unofficial. Зачем оно unofficial, когда в РФ есть сильное PG комьюнити?

Кроме того господин Федоров работает в EpicGames, если судить по сведениям профиля
в гите.

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

Сравнительно недавно один господин создавал сверхбыстрый логгер для java технологий
базируясь на самом медленном рантайме Groovy.

Также недавно (лет 5 назад) другой господин создавал свою DBMS с наносекундным откликом
несмотря на то что использовать ее собирался из .Net и просадил на накладных расходах 1000% неучтенного
времени в целом.

Вобщем все что очень-быстрое базируется на фейковых тестах которые зело быстры и стремительны
только на авторском сайте и иногда только на авторской постановке задачи.

Вот такие у меня concerns.

Против PG-драйвера я не имею ничего против. Я плюсую но хотел-бы понять где и как эту стократную цифру
можно получить? На ETL? На OLTP? Можно ли ее получить на платформерах (.Net, Java). Последнее мне
еще важнее.

Leonid KudryavtsevГлавный профит будет уменьшение трафика по сети. Ускорение - сильно сомневаюсь. В свое время перекачивал базу > 140 Gb из Oracle в PostgreSQL, делал через тектовый формат COPY - все упиралось в сервер (построение индексов), хоть он был нифига не слабый, а дисковая полка вообще отрабатывала за 0 ms (мгновенно, большой кэшь и подключение по FC)

Это вы дяденька маху дали. На миграциях - отключают индексы и триггера.
А потом включат rebuild..., enable without check... e.t.c..

Leonid KudryavtsevНо для ряда задач может быть ОЧЕНЬ осмысленно. Работал в проекте, где PostgreSQL использовался исключительно как хранилище BLOB'ов в которых и была сериализована вся информация. 2-х кратный трафик на BLOB'ах - для __данной__ задачи был сильно большим недостатком. Но это относительно редкое использование PostgreSQL (по факту, легко было бы на любую No-SQL базу поменять)
Недавно смотрел видос от Бартунова (это главный постгресщик по РФ). Он хвастался что в разработке
перформанса работы с JSON-B, они достигли таких высот что обошли MongoDB.

Leonid KudryavtsevmaytonЭто вы дяденька маху дали. На миграциях - отключают индексы и триггера.
А потом включат rebuild..., enable without check... e.t.c..
Я так и делал - оно почти фиолетово.
В средней БД. Объем индексного сегмента иногда равен общему объему таблиц. В db-blocks или в страницах.
Поэтому отключение этой ненужно дисковой активности очень помогает. Но возможно в вашем кейсе
сеть была настолько слаба что это мало влияло. Хотя должно было быть.

полудухmaytonНа 50 минут видоса смотреть? А есть краткое резюме о чем вещает бородатый господин?
слайды
О. Спасибо.

Хм... в конце слайдов уже написано что Федоров работает в Янддексе.

По поводу цифр. Никаких там сотни раз быстрее я не увидел. Где-то на восьмой странице
приводится столбчатые диаграммы с графиками с непонятными сценариями тестирования.

Сравниваются протоколы. Текстовый и двоичный. Безотносительно драйвера и программного продукта.
Сравниваются кейсы (предположительно) на Int64, Ts. В разрезах чтения записи и текстового и бианрного
протоколов. Итого получается 2*2*2 = 8 экспериментов.

Преимущество более чем в 2 раза у бинарного протокола вполне себе очевидно. И на этом всё.

Какие данные? какие типы транзакций OLTP? ETL?

Зачем мне нужен Int64? Я не понимаю. Мне нужен numeric(), varchar(), date(). Я с ними работаю
каждый день и много.

Вобщем ... много неясностей господа хорошие.