Подскажите, как лучше сделать? Есть таблица с большим количеством записей

о файлах. Буду делать агент, который проверяет наличие файла на своем месте и обновлять в таблице поле "дата-время последней проверки". При отсутствии файла будет вносится временная метка в поле "удален". Изредка будет возникать ситуация, когда файл, помеченный ранее как удаленный, снова будет найден на своем месте. Как лучше поступить с точки зрения скорости работы: для всех найденных файлов - обновлять одним запросом оба поля "дата-время последней проверки" и вносить Null в поле "удален" или, принимая во внимание то, что обнаружение на месте ранее удаленного файла - редкое событие предусмотреть отдельный запрос для сброса информации об удалении, а для всех файлов обновлять только одно поле?

Учитывая, что возвращать удалённое планируется редко -- без разницы. (Немного зависит от СУБД, в каких-нибудь колоночных бывает смысл это оптимзировать. Но тожэ не во всех).

А не получится так, что впустую заменяя Null на Null в 99.999% случаев я потрачу времени на замену двух полей больше чем на одно? (БД - MySQL.)

Нет, ему всё равно. Точнее, разница в сотни тактов не будет измеримой.

Спасибо! Принимая во внимание то, что первый вариант еще и короче по размеру кода его и выберу.

Всем классическим СУБД примерно всё равно -- они достают тапл для обновления цэликом, и потом цэликом его записывают. У некоторых есть оптимизацыи чтобы не бродить по индэксам и не трогать их если индэксируемое не сменилось -- но все сравнивают индэксированное значение до и после, им тожэ всё равно -- указано оно или нет.

Пг перестраивать будет. В пг как раз надо учитывать что и как ты апдейтишь.

Нет.

А с какой версии пг научился не трогать Индексы поля которых не менялись?

Сейчас pg не перестраивает если ни одно из индэксируемых полей не изменилось и на страницэ есть место для новой записи. И перестраивает если хоть одно изменилось. При этом изменение определяется побайтовым сравнением старого и нового полей тапла.

В районе 12. Лень искать. В 12 оно ужэ было, в 9.6 не было. Читайте про HOT UPDATE.

Кул. Читану. Фенкс.

И да, неважно -- есть там HOT UPDATE или нет. В любом случае -- путь изменений абсолютно одинаков, заменишь ты нормального размера поле на то жэ значение или нет.

С точки зрения скорости это пока рано, предъяви несколько решений, я смогу сказать, что быстрее, а что медленнее

А это как то экспереминтально увидеть можно?

Да нет же...

Да с рождения

1) update files set checkdate=sysdate(), deletedate=Null where path='Путь к файлу'; 2) update files set checkdate=sysdate() where path='Путь к файлу'; и отдельный блок для выявления восстановленных файлов.

Что именно из "этого"?

Увидеть хочу что не перестраиваются все Индексы при апдейт поля которое не в индексе.

Ну, можэшь сформировать HOT UPDATE и посмотреть через pageinspect, что получилось.

О. Точна. Пасиб.

При этом смотреть есть некоторый смысл при открытой транзакцыи -- иначе через небольшое время по идее вакуум вычистит лишнее и из HOT CHAIN и из индэкса, так что отличить одно от другого не получится.

одно и то же же

Спасибо!