Как стать автором
Обновить
241
29.1
Егор Рогов @erogov

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

Отправить сообщение

В 90х годах на коротких маршрутах она могла достигать 15 килограмм, а на длинных и все 30! Такой большой объем документации приводит к дополнительному расходу топлива, ...

И ведь не поспоришь!

... занимает лишнее место в кабине и пассажирском салоне, расходует огромное количество бумаги, что сильно вредит экологии и занимает много времени для её систематизации и изучения как кабинным экипажем, так и различными службами.

Интересно, что такое в вашем представлении кабинный экипаж.

Сама-то статья примерно никакая, но в первом комментарии Олег Бартунов оставил там ссылку на достоверную информацию.

Вы только не переживайте так. Ну неправильный слон, ну что делать. Но лучше ж, чем нейронкой картинки генерить.

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

Скажу так: если вы поклонник творчества Айзека Озимого

Айзек Озимый? Ну-ну.

Отдельно демобаза, конечно, тоже имеется (в книге есть все ссылки): https://postgrespro.ru/education/demodb

Да, любопытно, что выравнивание всей строки делает выигрыш от перестановки столбцов не таким большим, как хотелось бы.

А над тетрисом мудрые создатели демобазы совсем не думали (:

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

Да, вероятно.

Раздувание вряд ли - после снятия удержания TPS возвращаются к исходным.

Я бы как раз на него грешил. Много версий строк, надо все прочитать, чтобы выбрать нужную. А обратно может быстро возвращаться благодаря внутристраничной очистке.

Но вообще интересно было бы проанализировать.

Тут вопрос в том, почему TPS падают. Это только раздувание таблиц и индексов, или что-то ещё?

Самолёт преодолел точки и затмил солнце, расходимся.

аффторский

Отключение всех трёх JOIN ломает работу соединений, PostgreSQL выдаст ошибку.

Дивный новый мир: нейросеть что-то там нагенерила, автор даже не удосужился проверить.

Сложно-то как. А почему не посмотреть количество прочитанных буфером простым explain (analyze, buffers)?

(К слову, для ожиданий есть pg_wait_sampling, а для просмотра плана работающего запроса - pg_query_state).

Про красивую и осмысленную визуализацию данных неплохо почитать Эдварда Тафти.

Фантомное чтение (phantom read). Этот феномен очень похож на неповторяющееся чтение, но здесь идет чтение нескольких строк. Первая транзакция делает выборку набора строк. После этого приходит вторая транзакция и удаляет или добавляет строки попадающие в эту выборку. Вторая транзакция фиксирует свои изменения. После этого первая транзакция снова делает ту же самую выборку и уже получает другой набор строк - их стало либо больше, либо меньше чем при первой выборке, так как вторая транзакция добавила / удалила строки.

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

Сошлюсь на стандарт:

P3 (“Phantom”): SQL-transaction T1 reads the set of rows N that satisfy some <search condition>. SQL-transaction T2 then executes SQL-statements that generate one or more rows that satisfy the <search condition> used by SQL-transaction T1. If SQL-transaction T1 then repeats the initial read with the same <search condition>, it obtains a different collection of rows.

А удаление - это случай неповторяющегося чтения:

P2 (“Non-repeatable read”): SQL-transaction T1 reads a row. SQL-transaction T2 then modifies or deletes that row and performs a COMMIT. If T1 then attempts to reread the row, it may receive the modified value or discover that the row has been deleted.

1
23 ...

Информация

В рейтинге
276-й
Откуда
Москва, Москва и Московская обл., Россия
Работает в
Дата рождения
Зарегистрирован
Активность