В данном случае речь же не идет о том, какое представление более удобное или более эффективное. Просто у участников было такое условие задачи. Если формат данных кажется неудобным, вы можете легко добавить недостающие пункты и работать дальше уже с таким представлением.
А в реальных задачах решение о том, хранить или не хранить «пустышки» зависит от того, насколько разрежены данные, и от того, как вы собираетесь с ними работать.
Постгрес следует ISO-8601 и, насколько я помню, у него нет штатной возможности добраться до признака первого дня недели из локали. Поэтому решил не усложнять.
Признаться, не понял, какую задачу мы решаем и зачем. Если у нас уже есть Таблица Судьбы life, зачем нам конечный автомат? Вот если бы была таблица переходов, а на вход автомату подавались бы радости и невзгоды, определяющие, по какой ветке идти дальше — это бы имело для меня смысл.
Я не очень в курсе, как в Java реализованы хеш-таблицы (для буферного кеша используется динамически расширяемая таблица с разрешением коллизий с помощью цепочек), но по части конкурентного доступа - да, судя по всему, что-то похожее на ConcurrentHashMap.
По воспоминаниям, главной трудностью было отсутствие ответа на вопрос «зачем я это учу, что мне это даст, к чему это можно применить?». А сами-то по себе кванторы, эпсилоны и дельты логичны и красивы. ВМК.
Внимательный читатель уже хочет спросить: если xmin и xmax в кортеже остались 32–битные, то получается что на одной странице нельзя разместить данные с транзакций, отстоящих друг от друга больше, чем на 232?
Тут, мне кажется, интересный вопрос — насколько это серьезное ограничение с точки зрения эксплуатации? Ведь базовый xid страницы можно двигать вперед без оглядки на остальные страницы, то есть при любой заморозке, неважно, агрессивной или нет.
Насколько я понимаю, никакой концептуальной проблемы и не было. Надо было сделать фильтрацию по источнику, и вот ее сделали. Раньше, видимо, просто руки не доходили.
В данном случае речь же не идет о том, какое представление более удобное или более эффективное. Просто у участников было такое условие задачи. Если формат данных кажется неудобным, вы можете легко добавить недостающие пункты и работать дальше уже с таким представлением.
А в реальных задачах решение о том, хранить или не хранить «пустышки» зависит от того, насколько разрежены данные, и от того, как вы собираетесь с ними работать.
Все правильно, мы храним в таблице только камни, а не пустые пункты. Посмотрите примеры дальше.
На словах-то выглядит красиво, а вы покажите работающий код.
Постгрес следует ISO-8601 и, насколько я помню, у него нет штатной возможности добраться до признака первого дня недели из локали. Поэтому решил не усложнять.
Рад, что статьи помогают!
Сейчас наиболее актуальный источник — это книга «PostgreSQL изнутри». А обновлять и книгу, и статьи, увы, никаких сил не хватит.
А что это за зверь, о котором молчит документация? Где почитать?
Признаться, не понял, какую задачу мы решаем и зачем. Если у нас уже есть Таблица Судьбы
life, зачем нам конечный автомат? Вот если бы была таблица переходов, а на вход автомату подавались бы радости и невзгоды, определяющие, по какой ветке идти дальше — это бы имело для меня смысл.Мониторинг - и будет автоматическое средство. Но не встроенное, да.
Да, это так.
Я не очень в курсе, как в Java реализованы хеш-таблицы (для буферного кеша используется динамически расширяемая таблица с разрешением коллизий с помощью цепочек), но по части конкурентного доступа - да, судя по всему, что-то похожее на ConcurrentHashMap.
Пора, пора обновляться! Раз в пять лет-то можно себе позволить (:
(:
Читайте лучше книгу (https://postgrespro.ru/education/books/internals), а то статьи местами уже подустарели.
По воспоминаниям, главной трудностью было отсутствие ответа на вопрос «зачем я это учу, что мне это даст, к чему это можно применить?». А сами-то по себе кванторы, эпсилоны и дельты логичны и красивы. ВМК.
«PostgreSQL. Основы языка SQL» Евгения Моргунова — учебник для тех, кто работает с PostgreSQL. В электронном виде доступен свободно.
Вы уверены?
Тут, мне кажется, интересный вопрос — насколько это серьезное ограничение с точки зрения эксплуатации? Ведь базовый xid страницы можно двигать вперед без оглядки на остальные страницы, то есть при любой заморозке, неважно, агрессивной или нет.
Тут был бы уместен и хаб PostgreSQL.
Насколько я понимаю, никакой концептуальной проблемы и не было. Надо было сделать фильтрацию по источнику, и вот ее сделали. Раньше, видимо, просто руки не доходили.
Просто оставлю это здесь, как говорится:
http://citforum.ru/database/articles/evergreen_nulls/
Разве что создавать функции в схеме pg_temp, чтобы они автоматически удалялись.
Но не знаю, насколько это удачно. Скорее всего все же стоит что-то поменять в подходе. Во всяком случае, на DO с параметрами рассчитывать не стоит.