Pull to refresh
213
0
Егор Рогов @erogov

Пользователь

В детстве на меня упал граммофон

ключевым моментом в оптимизации медленных запросов является поиск последовательных сканов, которые выполняет БД, и добавление соответствующих индексов

...и ни слова про селективность. Дальше можно не читать.

Как минимум потому, что так написано в стандарте SQL.

Нет, ничего не "чинили" и не планируют. Ну, такая вот особенность.

Чтобы перебрать всю таблицу эффективно, нужно обычное последовательное сканирование, которое и получится при выполнении запроса `select * from table1`. Чтобы эффективно перебрать таблицу по условию `value = 100000`, как у вас в запросе, нужен индекс и, опять же, простой запрос `select * from table1 where value = 100000`.

А использовать ctid для этих задач — заведомый способ выполнить работу неэффективно. Не надо придумывать хитрые ходы там, где они не нужны.

Поздравляю, вы изобрели цепь Маркова.

и я и ты и я да и мы и ты и вы и

Напомнило

Перевод третьего издания PostGIS in Action недавно вышел в ДМК: «PostGIS в действии».

Значит, будут заниматься чем-то более интересным, почему нет? Хотя по своему опыту работы в кровавом энтерпрайзе могу сказать, что скучных задач было не так уж много, обычно хватало всякого веселья.

Убедительно! Да, этот вариант проще и лучше, спасибо!

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

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

А в реальных задачах решение о том, хранить или не хранить «пустышки» зависит от того, насколько разрежены данные, и от того, как вы собираетесь с ними работать.

Все правильно, мы храним в таблице только камни, а не пустые пункты. Посмотрите примеры дальше.

На словах-то выглядит красиво, а вы покажите работающий код.

Постгрес следует ISO-8601 и, насколько я помню, у него нет штатной возможности добраться до признака первого дня недели из локали. Поэтому решил не усложнять.

Рад, что статьи помогают!

Сейчас наиболее актуальный источник — это книга «PostgreSQL изнутри». А обновлять и книгу, и статьи, увы, никаких сил не хватит.

Одной из главных новинок является поддержка индексов с высокой степенью уникальности (High Unique Indexes)

А что это за зверь, о котором молчит документация? Где почитать?

Признаться, не понял, какую задачу мы решаем и зачем. Если у нас уже есть Таблица Судьбы life, зачем нам конечный автомат? Вот если бы была таблица переходов, а на вход автомату подавались бы радости и невзгоды, определяющие, по какой ветке идти дальше — это бы имело для меня смысл.

Мониторинг - и будет автоматическое средство. Но не встроенное, да.

Да, это так.

Information

Rating
3,465-th
Location
Москва, Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity