这可能是一个长镜头，但我想我还是会问。
我正在考虑将 Heroku 的新 Crane Postgres DB（400 MB RAM 缓存）与我在 Heroku 上部署的应用程序结合使用。400 MB 的缓存大小应该足以满足我们的需求……除了一张表的一列，我们将缓存的 PDF 文件存储为字符串。如果 Heroku 使用它的缓存，PDF 可以很容易地很快用完 400MB RAM。
如果我在一个实际的服务器上，我只是将 PDF 存储为一个文件，但考虑到 Heroku 的临时文件系统，如果我只是将 pdf 存储在数据库中而不是仅仅为了连接到 S3，我的生活会简单得多这件事。（这使我们正在考虑部署多个 heroku 实例，每个客户端一个......因此使用数据库比为每个实例创建一个新存储桶更简单。）我并不真正关心这方面的速度。如果人们正在获取文件，他们会期望速度就像它来自文件系统一样，因为大多数文件下载都是这样完成的。有什么方法可以告诉 PostGRES 不要打扰缓存此列？
或者也许我问错了问题，还有其他方法可以解决问题或设计替代方案，使其无关紧要。
你不必做任何事情。PostgreSQL 将自动对大于 8 kB 的值使用 TOAST。
来自http://www.postgresql.org/docs/9.1/static/storage-toast.html
PostgreSQL 使用固定的页面大小（通常为 8 kB），并且不允许元组跨越多个页面。因此，不可能直接存储非常大的字段值。为了克服这个限制，大字段值被压缩和/或分解成多个物理行。这对用户是透明的，对大多数后端代码的影响很小。该技术被亲切地称为 TOAST（或“自切片面包以来最好的东西”）。
PostgreSQL 缓存也在页面级别完成，因此 TOAST 不必与行的其余部分一起缓存（http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf）。
Postgres 可以 TOAST 大字段值这一事实并不意味着它是最好的选择。
如果您在主数据库中存储大字段，这将使许多事情变得更加困难，例如创建分叉或追随者，特别是创建和恢复备份。我会强烈重新考虑使用 S3 来存储 PDF 文件，并简单地投资于新客户的自动入职（创建 heroku 应用程序、配置数据库、配置/创建 S3 存储桶）。
我不太确定您如何管理存储大型 PDF，因为 Postgres 规定了最大字段大小（或至少是最大页面大小）。但是，您可以通过使用 TOAST 来解决这个问题。TOAST 项存储在单独的（物理）表中，因此如果您不经常选择它们，则不应缓存它们。
如果您经常选择它们，那么我不确定您想要的是否可行。请记住，Postgres 只提供一个“级别”的缓存——Linux VFS 也进行缓存。