А какое железо, сколько сеансов, чем они занимаются, что происходит при нулевом значении?.. Я к чему: чтобы извлечь что-то полезное, нужно много информации.
Ну как, задержки на легких блокировках больше. Насколько больше (или меньше) - это, конечно, надо тестировать на конкретной системе и конкретной нагрузке.
Но вообще я бы сказал, что без рекомендации техподдержки не стоит этот параметр трогать, разве что из любопытства.
Насколько я понимаю, «честная» очередь помогает только при большой конкуренции (много ядер, высокая нагрузка...), а в простых случаях работает хуже «нечестной». Поэтому кому надо — включат, а остальным это не нужно.
Чтобы перебрать всю таблицу эффективно, нужно обычное последовательное сканирование, которое и получится при выполнении запроса `select * from table1`. Чтобы эффективно перебрать таблицу по условию `value = 100000`, как у вас в запросе, нужен индекс и, опять же, простой запрос `select * from table1 where value = 100000`.
А использовать ctid для этих задач — заведомый способ выполнить работу неэффективно. Не надо придумывать хитрые ходы там, где они не нужны.
Значит, будут заниматься чем-то более интересным, почему нет? Хотя по своему опыту работы в кровавом энтерпрайзе могу сказать, что скучных задач было не так уж много, обычно хватало всякого веселья.
Михаил, спасибо, это было интересно!
Сертификация будет по 16-й версии, сразу за обновлением курсов на эту версию.
А какое железо, сколько сеансов, чем они занимаются, что происходит при нулевом значении?.. Я к чему: чтобы извлечь что-то полезное, нужно много информации.
Вот-вот. К тому же и не была dBase реляционной, в чем несложно убедиться, открыв мануал.
Так и страницы B-дерева не объединяются при удалении данных.
Ну как, задержки на легких блокировках больше. Насколько больше (или меньше) - это, конечно, надо тестировать на конкретной системе и конкретной нагрузке.
Но вообще я бы сказал, что без рекомендации техподдержки не стоит этот параметр трогать, разве что из любопытства.
Насколько я понимаю, «честная» очередь помогает только при большой конкуренции (много ядер, высокая нагрузка...), а в простых случаях работает хуже «нечестной». Поэтому кому надо — включат, а остальным это не нужно.
Давайте уже добавим причину минуса «отвратительный перевод».
Объём локальной памяти в коробке. Доставить эту установку до финиша...
Вот только запятую надо перенести на два разряда вправо: 99,998, до пяти девяток недотянули.
В детстве на меня упал граммофон
...и ни слова про селективность. Дальше можно не читать.
Конечно же нет.
Как минимум потому, что так написано в стандарте SQL.
Нет, ничего не "чинили" и не планируют. Ну, такая вот особенность.
Чтобы перебрать всю таблицу эффективно, нужно обычное последовательное сканирование, которое и получится при выполнении запроса `select * from table1`. Чтобы эффективно перебрать таблицу по условию `value = 100000`, как у вас в запросе, нужен индекс и, опять же, простой запрос `select * from table1 where value = 100000`.
А использовать ctid для этих задач — заведомый способ выполнить работу неэффективно. Не надо придумывать хитрые ходы там, где они не нужны.
Не поверите, купить.
Sanitarium
Leave me be
Поздравляю, вы изобрели цепь Маркова.
Напомнило
Перевод третьего издания PostGIS in Action недавно вышел в ДМК: «PostGIS в действии».
Значит, будут заниматься чем-то более интересным, почему нет? Хотя по своему опыту работы в кровавом энтерпрайзе могу сказать, что скучных задач было не так уж много, обычно хватало всякого веселья.
Убедительно! Да, этот вариант проще и лучше, спасибо!
Такая мысль у меня была с самого начала, но что-то у меня не заладилось с реализацией, я переключился на массивы и обратно уже не вернулся.