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

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

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

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

既然如此，當(dāng)我們?cè)诓樵冎杏玫絚tid時(shí)，是否還能使用index only scan呢？

按理來(lái)說(shuō)是沒(méi)有問(wèn)題的，例如在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，取而代之的是普通的索引掃描。

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

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

傳送門

解答是說(shuō)和HOT有關(guān)，乍一看似乎有點(diǎn)道理，但是仔細(xì)想想，如果是HOT那么也會(huì)通過(guò)vm文件去判斷多版本，那么對(duì)于ctid我們只要通過(guò)vm文件判斷其可見(jiàn)性不是就可以了，至少當(dāng)表中沒(méi)有任何不可見(jiàn)的行時(shí)應(yīng)該要使用index only scan啊。

這其實(shí)因?yàn)樵谑褂胿m文件進(jìn)行可見(jiàn)性判斷前，優(yōu)化器在parse階段就已經(jīng)決定了是使用index scan還是index only scan，通過(guò)check_index_only函數(shù)來(lái)判斷是否使用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);

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

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

您可能感興趣的文章: