Pull to refresh
243
20.1
Егор Рогов @erogov

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

Send message

Насколько я понимаю, «честная» очередь помогает только при большой конкуренции (много ядер, высокая нагрузка...), а в простых случаях работает хуже «нечестной». Поэтому кому надо — включат, а остальным это не нужно.

Давайте уже добавим причину минуса «отвратительный перевод».

Объём локальной памяти в коробке. Доставить эту установку до финиша...

Вот только запятую надо перенести на два разряда вправо: 99,998, до пяти девяток недотянули.

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

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

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

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

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

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

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

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

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

Напомнило

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

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

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

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

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

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

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

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

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

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

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

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

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

Information

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