据我所知，数据库可以延迟写入表文件以提高IO性能。当事务被COMMIT ted时，数据被写入WAL文件。我很好奇，写表文件会有多大的延迟，特别是当我使用一个简单的SELECT时，例如：
COMMIT
SELECT
SELECT * from myTable;
在COMMIT之后，除了表文件之外，数据库是否还必须从WAL文件中检索数据？
zte4gxcn1#
documentation谈到了能够延迟数据页的刷新：如果我们遵循此过程，就不需要在每次事务提交时将数据页刷新到磁盘。WAL文件允许RDBMS做的事情是将“脏”数据页保存在内存中，并在以后将它们刷新到磁盘上，而不是在以后修改数据页。因此，您的问题的答案是“不，SELECT总是从数据页检索数据，而不是从WAL文件”。
6vl6ewon2#
PostgreSQL在正常运行时不会读取WAL，它只会读取WAL，以便在崩溃后（或复制到另一个服务器时）将更改应用到数据文件。当普通数据文件中的数据发生更改时，数据文件的页面将保留在共享内存中（在shared_buffers中），直到它们被写入磁盘。任何其他想要查看该数据的进程都将在该共享内存中找到它，并且它将以其更改后的形式存在。它们在尝试从磁盘读取数据之前，总是会在shared_buffers中查找它，因此，除了崩溃后的恢复过程之外，没有人会看到陈旧的磁盘上的数据版本。
2条答案
按热度按时间zte4gxcn1#
documentation谈到了能够延迟数据页的刷新：
如果我们遵循此过程，就不需要在每次事务提交时将数据页刷新到磁盘。
WAL文件允许RDBMS做的事情是将“脏”数据页保存在内存中，并在以后将它们刷新到磁盘上，而不是在以后修改数据页。
因此，您的问题的答案是“不，SELECT总是从数据页检索数据，而不是从WAL文件”。
6vl6ewon2#
PostgreSQL在正常运行时不会读取WAL，它只会读取WAL，以便在崩溃后（或复制到另一个服务器时）将更改应用到数据文件。
当普通数据文件中的数据发生更改时，数据文件的页面将保留在共享内存中（在shared_buffers中），直到它们被写入磁盘。任何其他想要查看该数据的进程都将在该共享内存中找到它，并且它将以其更改后的形式存在。它们在尝试从磁盘读取数据之前，总是会在shared_buffers中查找它，因此，除了崩溃后的恢复过程之外，没有人会看到陈旧的磁盘上的数据版本。