Разбередили память Паскалем... Погуглил... Оказывается, у динамических массивов индексация была с нуля. А вот у строк типа string индексация символов была с единицы.
И почему-то мне казалось, что в какой-то из версий Паскаля можно было объявить массив, указывая только размер, но не нагуглилось. Видимо, фантомная память...
"LIKE '%abc%' и LIKE '%abc' НЕ используют индексы." Не знаю как в PostgreSQL, а вообще индекс тут может быть использован для полного сканирования индекса вместо полного сканирования таблицы.
Стоило бы убрать Big Data из тэгов, к бигдате статья не имеет отношения. И добавить PostgreSQL в заголовок и в тэги. Как раньше пользователи MS SQL считали, что он и есть SQL, так теперь пользователи PostgreSQL считают, что он и есть SQL. Хотя, разумеется, это не так в обоих случаях.
Статья банальная, такие регулярно выходят на Хабре. Ничего нового не увидел.
В ряде мест подача какая-то вывернутая наизнанку. Например, не BETWEEN выполняется быстрее, а использование конструкции функция(поле) часто делает невозможным использование индекса по этому полю. Но это не значит, что BETWEEN обладает каким-то особенным волшебством.
Почему-то под картинками подпись "Скорость ...", хотя на них никакой скорости не отображено. Возможно проглядел, но во всей статье не увидел ничего про скорость.
Некоторые советы сомнительные и нуждаются в тщательной аргументации, например, "Использование ранжирования вместо DISTINCT".
"Использование CTE может помочь оптимизировать вычисления". А может и не помочь. В других SQL-движках встречал вред от CTE, когда CTE выполняется несколько раз (по числу ссылок на него в запросе) и, как следствие, несколько раз читает огромную таблицу.
"Обнаружилось, что при большом количестве значений скорость запроса сильно падает, если используется IN. Это происходит потому, что значение колонки каждой строки поочерёдно сравнивается с каждым из возможных вариантов, тем самым нагружая процессор." Даже MySQL древних версий умеет из значений в IN строить бинарное дерево и находить соответствие за O(log(n))-время. Неужели PostgreSQL не умеет?
И странное дело - вроде бы картинки в статье в png-формате, однако шрифты дико замылены, как будто их сохраняли в jpg формат с хорошим сжатием.
Подскажите, пожалуйста, как по этой ссылке скачать pdf-файл? Как ни пытаюсь, все какая-то ерунда получается.
И можно попросить добавить в пост оглавление книги и хотя бы краткое вступление - о чем она, для кого она, какая подготовка требуется перед ее прочтением и т.п. ?
Не знаю какие механизмы защиты от этого есть/были у Амазон, но он мог списывать деньги за покупки без CVC-кода. Правда, я сам с этим сталкивался достаточно давно, лет 10 назад или более. Но есть и более свежие упоминания, например, см. https://qna.habr.com/q/34795
Например, для того, чтобы мне на карту зачисляли зарплату, я сообщал номер счета, к которому она привязана. А обычные люди вокруг меня все переводят по номеру телефона.
И напрасно. Он может быть использован как элемент социальной инженерии. Или мошенники могут узнать CVC по другим каналам. А в некоторых случаях возможно и прямое списание средств.
Разбередили память Паскалем... Погуглил... Оказывается, у динамических массивов индексация была с нуля. А вот у строк типа string индексация символов была с единицы.
И почему-то мне казалось, что в какой-то из версий Паскаля можно было объявить массив, указывая только размер, но не нагуглилось. Видимо, фантомная память...
"Вы потеряли всё 31 июля "
Да, вы правы, я забыл поправить на 1 августа.
В PostgreSQL это, вероятно, нормально.
В других СУБД надо смотреть на правила неявного преобразования типов данных.
Если реальное содержимое поля orderdate имеет значения с долями секунд, то ваш вариант потеряет данные из последней секунды.
Если в orderdate долей секунд не бывает, то исходный вариант зацепит лишнюю секунду.
Чтобы не сомневаться, я бы написал так:
WHERE orderdate >= '2006-07-01 00:00:00'::TIMESTAMPAND orderdate < '2006-07-31 00:00:00'::TIMESTAMP
"LIKE '%abc%' и LIKE '%abc' НЕ используют индексы."
Не знаю как в PostgreSQL, а вообще индекс тут может быть использован для полного сканирования индекса вместо полного сканирования таблицы.
Стоило бы убрать Big Data из тэгов, к бигдате статья не имеет отношения. И добавить PostgreSQL в заголовок и в тэги. Как раньше пользователи MS SQL считали, что он и есть SQL, так теперь пользователи PostgreSQL считают, что он и есть SQL. Хотя, разумеется, это не так в обоих случаях.
Статья банальная, такие регулярно выходят на Хабре. Ничего нового не увидел.
В ряде мест подача какая-то вывернутая наизнанку. Например, не BETWEEN выполняется быстрее, а использование конструкции функция(поле) часто делает невозможным использование индекса по этому полю. Но это не значит, что BETWEEN обладает каким-то особенным волшебством.
Почему-то под картинками подпись "Скорость ...", хотя на них никакой скорости не отображено.
Возможно проглядел, но во всей статье не увидел ничего про скорость.
Некоторые советы сомнительные и нуждаются в тщательной аргументации, например, "Использование ранжирования вместо DISTINCT".
"Использование CTE может помочь оптимизировать вычисления".
А может и не помочь. В других SQL-движках встречал вред от CTE, когда CTE выполняется несколько раз (по числу ссылок на него в запросе) и, как следствие, несколько раз читает огромную таблицу.
"Обнаружилось, что при большом количестве значений скорость запроса сильно падает, если используется IN. Это происходит потому, что значение колонки каждой строки поочерёдно сравнивается с каждым из возможных вариантов, тем самым нагружая процессор."
Даже MySQL древних версий умеет из значений в IN строить бинарное дерево и находить соответствие за O(log(n))-время. Неужели PostgreSQL не умеет?
И странное дело - вроде бы картинки в статье в png-формате, однако шрифты дико замылены, как будто их сохраняли в jpg формат с хорошим сжатием.
Спасибо!
Вот этого "не сразу" я и не дожидался. Сейчас специально замерил, у меня это заняло 15 секунд.
Какой-то последовательностью перемещения по github-у скачать файл получилось, но воспроизвести уже не получается.
По этой ссылке открывается github, который говорит "Unable to render code block ".
Подскажите, пожалуйста, как по этой ссылке скачать pdf-файл?
Как ни пытаюсь, все какая-то ерунда получается.
И можно попросить добавить в пост оглавление книги и хотя бы краткое вступление - о чем она, для кого она, какая подготовка требуется перед ее прочтением и т.п. ?
У меня такое недавно было. Оказалось, что деактивировался какой-то аккаунт, который когда-то раньше поставил мне -1.
Вот тоже хотел спросить какой-нибудь справочник. Не понимаю, что второй слева и третий обозначают.
Не знаю какие механизмы защиты от этого есть/были у Амазон, но он мог списывать деньги за покупки без CVC-кода. Правда, я сам с этим сталкивался достаточно давно, лет 10 назад или более. Но есть и более свежие упоминания, например, см. https://qna.habr.com/q/34795
Например, для того, чтобы мне на карту зачисляли зарплату, я сообщал номер счета, к которому она привязана. А обычные люди вокруг меня все переводят по номеру телефона.
И напрасно. Он может быть использован как элемент социальной инженерии. Или мошенники могут узнать CVC по другим каналам.
А в некоторых случаях возможно и прямое списание средств.
А как насчет резисторов с проволочными выводами?
Еще бы здорово было с камеры/картинки распознавать компоненты, хотя бы самые простые, те же резисторы. Как россыпью на столе, так и на плате.
Спрашивали про расстояние, а вы отвечаете про путь.
Или несколько полных окружностей. Т.е. количество подходящих точек бесконечно.
Хм, но зато часть сайтов отвалилась, в т.ч. хабр. Придется переключать туда-сюдя.
Спасибо! Помогло даже для Ростелеком (Москва), а до сих пор ничего не помогало.
Это предполагает регистрацию в системе?
Если да, то я не стал бы ей пользоваться ни как соискатель, ни как собеседующий