接前面。

回到程序調用關系上來：

estimate_rel_size -> RelationGetNumberOfBlocks->RelationGetNumberOfBlocksINFork

->Smgrnblocks->mdnblocks...

折騰了一圈，就是為了評估一個表的大小。

那么，我們所獲得的block，它到底是個什么單位？

BlockNumber mdnblocks(SMgrRelation reln, ForkNumber forknum) {MdfdVec *v = mdopen(reln, forknum, EXTENSION_FAIL);BlockNumber nblocks;BlockNumber segno = 0;/** Skip through any segments that aren't the last one, to avoid redundant* seeks on them. We have previously verified that these segments are* exactly RELSEG_SIZE long, and it's useless to recheck that each time.** NOTE: this assumption could only be wrong if another backend has* truncated the relation. We rely on higher code levels to handle that* scenario by closing and re-opening the md fd, which is handled via* relcache flush. (Since the checkpointer doesn't participate in* relcache flush, it could have segment chain entries for inactive* segments; that's OK because the checkpointer never needs to compute* relation size.)*/while (v->mdfd_chain != NULL){segno++;v = v->mdfd_chain;}for (;;){ nblocks = _mdnblocks(reln, forknum, v);fprintf(stderr,"%d blocks by process %d\n\n",nblocks,getpid());if (nblocks > ((BlockNumber) RELSEG_SIZE))elog(FATAL, "segment too big");if (nblocks < ((BlockNumber) RELSEG_SIZE))return (segno * ((BlockNumber) RELSEG_SIZE)) + nblocks;/** If segment is exactly RELSEG_SIZE, advance to next one.*/segno++;if (v->mdfd_chain == NULL){/** Because we pass O_CREAT, we will create the next segment (with* zero length) immediately, if the last segment is of length* RELSEG_SIZE. While perhaps not strictly necessary, this keeps* the logic simple.*/v->mdfd_chain = _mdfd_openseg(reln, forknum, segno, O_CREAT);if (v->mdfd_chain == NULL)ereport(ERROR,(errcode_for_file_access(),errmsg("could not open file \"%s\": %m",_mdfd_segpath(reln, forknum, segno))));}v = v->mdfd_chain;} }

還是用實驗來驗證一下吧：

先建立表:

postgres=# create table tst01(id integer); CREATE TABLE postgres=# postgres=# select oid from pg_class where relname='tst01';oid -------16384 (1 row)

據我所知，PostgreSQL中，integer類型的數據會在每條記錄中占用4個字節。

那么我想，4字節×2048條記錄=8192字節，也就是8K。

事實如何呢？

[root@lex base]# ls ./12788/16384 ./12788/16384postgres=# insert into tst01 values(generate_series(1,2048)); INSERT 0 2048 postgres=# [root@lex base]# ls -lrt ./12788/16384 -rw------- 1 postgres postgres 81920 May 28 11:54 ./12788/16384 [root@lex base]# ls -lrt -kb ./12788/16384 -rw------- 1 postgres postgres 80 May 28 11:54 ./12788/16384 [root@lex base]#

不是8K，而是 80K！

數據量再翻上一倍會如何？

postgres=# insert into tst01 values(generate_series(2049,4096)); INSERT 0 2048 postgres=#[root@lex base]# ls -lrt -kb ./12788/16384 -rw------- 1 postgres postgres 152 May 28 11:56 ./12788/16384 [root@lex base]#

原本我以為，8K為單位的block，僅僅是一小部分是冗余數據（如Header），但事實是并非這樣。

問了牛人，得到的答復是：

postgres=# select pg_column_size(id) from tst01 limit 1;pg_column_size ----------------4 (1 row)postgres=# select pg_column_size(t) from tst01 t limit 1;pg_column_size ----------------28 (1 row)

?然后再來看程序里對block的處理：

postgres=# select count(*) from tst01;count -------4096 (1 row)postgres=#

此時，后臺輸出的是：

19 blocks by process 4920

19是什么概念：

[root@lex 12788]# ls -lrt 16384 -rw------- 1 postgres postgres 155648 May 28 11:58 16384 [root@lex 12788]# 155648/8096 = 19.225296442688

正好合拍。所以PostgreSQL的源代碼中，mdnblocks 取得的block數目，就是 8K為單位的數據塊的個數。

從前面的小實驗中也可以看到，如果一條記錄中的數據較少，header部分所占冗余就占比較大了。

因此，如果想要正確評估一個表所占用的實際空間，基本上要靠抽樣了。

?

總結

以上是生活随笔為你收集整理的PostgreSQL在何处处理 sql查询之二十二的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。