只是甲的博客

PG版本:14.3。

PostgreSQL的主要结构如下：PostgreSQL进程结构图谱和分类:内存结构分为共享内存、本地内存。类似于Oracle的SGA和PGA。共享内存是指数据库服务器向操作系统申请的共享内存段，如数据共享缓冲区、日志缓冲区、事务提交日志内存区等，提供给PostgreSQL服务器的所有进程使用。数据共享缓冲区：PostgreSQL把要操作和处理的表、index，读入到内存中，放到该区域缓存。类似于Oracle的database buffer cache。其大小由shared_buffers参数决定。日

这里修改的是Linux系统登录的账号密码，不是PostgreSQL数据库的密码，后面会修改PostgreSQL数据库的密码。安装完PostgreSQL数据库以后，默认会创建一个名为postgres的Linux登录用户名，这里需要进行密码修改。用postgres账号登录Centos，并修改数据库用户密码（或者直接su postgres切换过去）选择Download。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1Zd0Ips8-1686533614058)(https://upload-images.jianshu.io/upload_images/2638478-38f401bb74f6a96b.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]选择Download。

shared hit代表的是缓存的数据块，一个数据块默认是8k，算上和表的总数差不多了，所以直接从内存读会比通过索引回表块，此时当然就直接走全表从内存中读取了。因为buffers是全局的，而且这个环境是生产环境，我暂时不好处理，于是就等了几分钟，重新运行查询。今天开发的找到我，说他创建了一个索引，但是查看执行计划，依旧走的是全表扫描，很让人头疼。我把复杂问题简单化，就单表执行where条件查询表，看能不能重现开发说的问题。我看了下居然真的走了全表扫描，不过我看了下，基本上都在buffers中缓存了。

为了缓解这个问题，PostgreSQL引入了可见性映射（visibility map），这是一种数据结构，用于存储每个人是否都可以看到表块中的所有元组。对于count(*) 操作，完全可以借助索引，因为索引占的空间比表小太多，那么几十M的索引扫描起来为什么那么慢呢?遇到的问题是，第一次执行会很慢，6秒左右，如果间隔时间段第二次执行，因为缓存了第一次的数据，所以查询很快。开启4个并行，并调整参数后，我进行了5次测试，以示公平，每次测试后，休眠5分钟。前端页面需要分页展示，经常需要查询总数，然后做分页展示。