接前面。

回到程序調(diào)用關(guān)系上來(lái)：

estimate_rel_size -> RelationGetNumberOfBlocks->RelationGetNumberOfBlocksINFork

->Smgrnblocks->mdnblocks...

折騰了一圈，就是為了評(píng)估一個(gè)表的大小。

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

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;} }

還是用實(shí)驗(yàn)來(lái)驗(yàn)證一下吧：

先建立表:

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

據(jù)我所知，PostgreSQL中，integer類型的數(shù)據(jù)會(huì)在每條記錄中占用4個(gè)字節(jié)。

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

事實(shí)如何呢？

[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！

數(shù)據(jù)量再翻上一倍會(huì)如何？

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，僅僅是一小部分是冗余數(shù)據(jù)（如Header），但事實(shí)是并非這樣。

問(wèn)了牛人，得到的答復(fù)是：

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)

?然后再來(lái)看程序里對(duì)block的處理：

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

此時(shí)，后臺(tái)輸出的是：

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數(shù)目，就是 8K為單位的數(shù)據(jù)塊的個(gè)數(shù)。

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

因此，如果想要正確評(píng)估一個(gè)表所占用的實(shí)際空間，基本上要靠抽樣了。

?

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。