Как индекс btree, равный PostgreSQL, обеспечивает управление несколькими версиями параллелизма? - PullRequest
0 голосов
/ 23 февраля 2020

PostgreSQL ИСПОЛЬЗУЕТ MV CC технологию для управления параллелизмом базы данных, создания новой версии элемента для каждой записи и последующего доступа к этой версии через правила видимости. Вопрос в том, как индекс btree реализует управление несколькими версиями? Когда добавляются новые узлы btree и дерево разделяется, исходная структура btree будет изменена. В настоящее время как обрабатывается PG SQL? Может кто-нибудь подсказать?

1 Ответ

2 голосов
/ 23 февраля 2020

В PostgreSQL индексы не реализуют MV CC. Индекс содержит каждую строку, которая может быть кому-то интересна, начиная от строк, которые были вставлены, но еще не зафиксированы, до строк, которые полностью устарели, но еще не удалены. Вы должны посетить сам стол, чтобы увидеть, интересна ли вам эта строка.

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

Когда добавляются новые узлы btree и дерево разделяется, исходная структура btree будет изменена. В настоящее время, как обрабатывается PG SQL? Кто-нибудь может мне сказать?

Не думаю, что это действительно вопрос типа переполнения стека. Лучшая ссылка на все детали - это исходный код и исходные комментарии. Возможно, вам просто интересно, что произойдет, если транзакция откатится. Разделение страницы остается, и вставленный кортеж остается там до тех пор, пока вакуум не удалит его (в этот момент разделение страницы все еще остается).

В случае cra sh, либо запись WAL, которая описывает разделение воспроизводится или нет. Поскольку страницы, загрязненные разделением, не могут быть записаны до тех пор, пока запись WAL, описывающая разделение, не будет записана на диск (до тех пор они сохраняются в shared_buffers), система в любом случае будет находиться в согласованном состоянии.

...