mysterious nbtree.c comment
От | Greg Stark |
---|---|
Тема | mysterious nbtree.c comment |
Дата | |
Msg-id | 874pxys9zt.fsf@stark.xeocode.com обсуждение исходный текст |
Ответы |
Re: mysterious nbtree.c comment
Re: mysterious nbtree.c comment |
Список | pgsql-hackers |
In nbtree.c there's a path that calls btvacuumscan to gather statistics if there aren't already statistics. I'm not exactly clear how this code path is reached but that's not my question. There's a comment that "there's no need to go through all the vacuum-cycle-ID pushups" in this case because no deletions are being performed. I don't see how the lack of deletions is relevant to needing vacuum-cycle-ID. AFAICT there's still a risk that someone will come along and do a page split underneath this scan and if the page is to the left of the scan it will be missed. Datum btvacuumcleanup(PG_FUNCTION_ARGS) {IndexVacuumInfo *info = (IndexVacuumInfo *) PG_GETARG_POINTER(0);IndexBulkDeleteResult *stats = (IndexBulkDeleteResult *)PG_GETARG_POINTER(1); /* * If btbulkdelete was called, we need not do anything, just return * the stats from the latest btbulkdelete call. Ifit wasn't called, * we must still do a pass over the index, to recycle any newly-recyclable * pages and to obtain indexstatistics. * * Since we aren't going to actually delete any leaf items, there's no * need to go through all the vacuum-cycle-IDpushups. */if (stats == NULL){ stats = (IndexBulkDeleteResult *) palloc0(sizeof(IndexBulkDeleteResult)); btvacuumscan(info, stats, NULL, NULL, 0);} -- greg
В списке pgsql-hackers по дате отправления: