pgsql: Prevent synchronized scanning when systable_beginscan chooses a
В списке pgsql-committers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | pgsql: Prevent synchronized scanning when systable_beginscan chooses a |
| Дата | |
| Msg-id | E1SYQ8K-0006uE-Rh@gemulon.postgresql.org обсуждение |
| Список | pgsql-committers |
Prevent synchronized scanning when systable_beginscan chooses a heapscan. The only interesting-for-performance case wherein we force heapscan here is when we're rebuilding the relcache init file, and the only such case that is likely to be examining a catalog big enough to be syncscanned is RelationBuildTupleDesc. But the early-exit optimization in that code gets broken if we start the scan at a random place within the catalog, so that allowing syncscan is actually a big deoptimization if pg_attribute is large (at least for the normal case where the rows for core system catalogs have never been changed since initdb). Hence, prevent syncscan here. Per my testing pursuant to complaints from Jeff Frost and Greg Sabino Mullane, though neither of them seem to have actually hit this specific problem. Back-patch to 8.3, where syncscan was introduced. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/532fe28dade9291b7a7f7de3920a4d997bbd86a1 Modified Files -------------- src/backend/access/index/genam.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-)
В списке pgsql-committers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера