对pg_buffercache 的利用实验

简介:

先看有没有脏数据:

postgres=# select isdirty from pg_buffercache where isdirty='t';
isdirty 
---------
(0 rows)

此时尚未有脏数据。

进一步确认:

postgres=# select count(*) from pg_buffercache where isdirty='f';
count 
-------
180
(1 row)

postgres=# select count(*) from pg_buffercache where isdirty='t';
count 
-------
0
(1 row)

为f 的个数是180, 为t的个数仍然为零。

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

有一部分数据是空的。这可能象征着buffer中尚未被使用的数据区域。

建表,插入数据, 再看有没有脏数据,这是有了17条。

但是一旦关联 pg_class, 发现一条也无,估计是一些内部数据,暂时不理:

postgres=# create table testtab(id integer, val varchar(10));
CREATE TABLE
postgres=# insert into testtab values(1,'12345');
INSERT 0 1
postgres=# select count(*) from pg_buffercache where isdirty='t';
count 
-------
17
(1 row)

 


postgres=# select c.relname from pg_buffercache b, pg_class c where b.relfilenode=c.relfilenode and b.isdirty='t';
relname 
---------
(0 rows)

postgres=# select c.relname from pg_buffercache b, pg_class c where b.relfilenode=c.relfilenode;
relname 
-----------------------------------
pg_statistic
pg_statistic
pg_amop_fam_strat_index
pg_amop_fam_strat_index
pg_amop_fam_strat_index
pg_amop_opr_fam_index
pg_amop_opr_fam_index
pg_amop_opr_fam_index
pg_amproc_fam_proc_index
pg_amproc_fam_proc_index
pg_amproc_fam_proc_index
pg_aggregate_fnoid_index
pg_aggregate_fnoid_index
pg_cast_source_target_index
pg_cast_source_target_index
testtab
pg_index_indrelid_index
pg_index_indrelid_index
pg_index_indexrelid_index
pg_index_indexrelid_index
pg_operator_oid_index

.....

再来修改数据,看脏数据有否:

postgres=# select * from testtab;
id | val 
----+-------
1 | 12345
(1 row)

postgres=# update testtab set val='45678' where id=1;
UPDATE 1
postgres=# select c.relname from pg_buffercache b, pg_class c where b.relfilenode=c.relfilenode and b.isdirty='t';
relname 
---------
testtab
(1 row)

postgres=#

脏数据确实产生了。







本文转自健哥的数据花园博客园博客,原文链接:http://www.cnblogs.com/gaojian/archive/2012/10/25/2738682.html,如需转载请自行联系原作者

目录
相关文章
|
Oracle 安全 关系型数据库
|
SQL 并行计算 Oracle
论文解读|从论文到工程实现:PolarDB Cost Based查询改写
论文解读|从论文到工程实现:PolarDB Cost Based查询改写
181 0
|
机器学习/深度学习 SQL 算法
【DB吐槽大会】第58期 - PG 复杂JOIN优化器有巨大提升空间
大家好,这里是DB吐槽大会,第58期 - PG 复杂JOIN优化器有巨大提升空间
|
SQL 监控 关系型数据库
【DB吐槽大会】第71期 - PG pg_stat_statements缺乏p99, p95的指标
大家好,这里是DB吐槽大会,第71期 - PG pg_stat_statements缺乏p99, p95的指标
|
关系型数据库 调度 数据库
|
关系型数据库 PostgreSQL
PgSQL · 新特征 · PG11并行Hash Join介绍
关键字 Parallelized, Parallel-aware hash joins 摘要 本文将介绍一下PostgreSQL 11 beta 1 新增的全并行Hash join特征。 将给读者介绍一下postgreSQL并行的设计与实现,并分析一下PostgreSQL的全并行hash join的设计与实现细节。
2058 0
|
关系型数据库 PostgreSQL
|
关系型数据库 PostgreSQL