PostgreSQL在何处处理 sql查询之二十二
接前面。
回到程序調(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 492019是什么概念:
[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)題。
- 上一篇: android安全问题(二) 程序锁
- 下一篇: MySQL字符串截取函数