PostgreSQL索引掃描時為什么index only scan不返回ctid

更新時間：2022年09月19日 10:11:01 作者：foucus、

這篇文章主要介紹了PostgreSQL索引掃描時為什么index only scan不返回ctid的原因探索，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧

我們都知道在PostgreSQL中使用索引掃描時，是通過索引中存儲的ctid去表中得到數(shù)據(jù)的。同時在PostgreSQL中如果要查詢的列都在索引中，我們還可以使用index only scan。

既然如此，當我們在查詢中用到ctid時，是否還能使用index only scan呢？

按理來說是沒有問題的，例如在Oracle中：

SQL> select rowid,id from t1 where id = 1;
---------------------------------------------------------------------------
| Id  | Operation        | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT |        |     1 |    25 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IDX_T1 |     1 |    25 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------

我們的查詢包含了rowid，仍然不需要回表TABLE ACCESS BY INDEX ROWID BATCHED的步驟。但是在PostgreSQL似乎并不是這樣。

index only scan：

bill=# explain analyze select c1 from t1 where c1 = 10;
                                                     QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
 Index Only Scan using idx_t1 on t1  (cost=0.29..10.74 rows=523 width=4) (actual time=0.021..0.117 rows=523 loops=1)
   Index Cond: (c1 = 10)
   Heap Fetches: 0
 Planning Time: 0.076 ms
 Execution Time: 0.196 ms
(5 rows)

帶上ctid后：

bill=# explain analyze select ctid,c1 from t1 where c1 = 10;
                                                   QUERY PLAN
-----------------------------------------------------------------------------------------------------------------
 Index Scan using idx_t1 on t1  (cost=0.29..81.71 rows=523 width=10) (actual time=0.038..0.447 rows=523 loops=1)
   Index Cond: (c1 = 10)
 Planning Time: 0.098 ms
 Execution Time: 0.537 ms
(4 rows)

可以看到?jīng)]有再去使用index only scan，取而代之的是普通的索引掃描。

為什么會這樣呢？ctid必然是包含在任何btree索引中的，為什么用到ctid的時候就不能用index only scan？

在網(wǎng)上看到類似的問題：

傳送門

解答是說和HOT有關，乍一看似乎有點道理，但是仔細想想，如果是HOT那么也會通過vm文件去判斷多版本，那么對于ctid我們只要通過vm文件判斷其可見性不是就可以了，至少當表中沒有任何不可見的行時應該要使用index only scan啊。

這其實因為在使用vm文件進行可見性判斷前，優(yōu)化器在parse階段就已經(jīng)決定了是使用index scan還是index only scan，通過check_index_only函數(shù)來判斷是否使用index only scan：

for (i = 0; i < index->ncolumns; i++)
{
	int			attno = index->indexkeys[i];
	/*
	 * For the moment, we just ignore index expressions.  It might be nice
	 * to do something with them, later.
	 */
	if (attno == 0)
		continue;
	if (index->canreturn[i])
		index_canreturn_attrs =
			bms_add_member(index_canreturn_attrs,
						   attno - FirstLowInvalidHeapAttributeNumber);
	else
		index_cannotreturn_attrs =
			bms_add_member(index_cannotreturn_attrs,
						   attno - FirstLowInvalidHeapAttributeNumber);
}
index_canreturn_attrs = bms_del_members(index_canreturn_attrs,
										index_cannotreturn_attrs);
/* Do we have all the necessary attributes? */
result = bms_is_subset(attrs_used, index_canreturn_attrs);

簡單解釋下上面這段代碼的邏輯，pg在判斷是否使用index only scan時，就是將索引列取出放到一個bitmap位圖index_canreturn_attrs中，將查詢用到的列放到一個bitmap位圖attrs_used中，然后判斷attrs_used位圖是否是index_canreturn_attrs的子集，如果是則使用index only scan，而這里的index_canreturn_attrs信息是從pg_index中去獲取的，自然是不會存放ctid的信息。

到此這篇關于PostgreSQL索引掃描時為什么index only scan不返回ctid的文章就介紹到這了,更多相關PostgreSQL index only scan內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: