Home/ Questions/Q 8200057
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T06:18:17+00:00

This may be a long shot, but I thought I’d ask anyway. I am

  • 0

This may be a long shot, but I thought I’d ask anyway.

I am looking at using Heroku’s new Crane Postgres DB (400 MB RAM Cache) in conjunction with an app I’m deploying on Heroku. The 400 MB cache size should be plenty for our needs… except for one column of one table, in which we store a cached PDF file as a string. The PDF’s could easily use up the 400MB RAM pretty quickly if Heroku uses its Cache for them.

If I were on an actual server, I’d just store the PDF as a file, but given Heroku’s ephemeral file system, my life is much simpler if I just store the pdf in the DB rather than rigging up a connection to S3 just for this one thing. (It further complicates that we’re looking at deploying multiple heroku instances, one for each client … so using the DB’s is simpler than creating a new bucket for each one.) I don’t really care about the speed on this. If people are getting the file, they will expect speeds as if it were coming from a file system anyhow, since thats how most file downloads are done. Is there any way to tell PostGRES to not bother caching this column?

Or maybe I’m asking the wrong question, and there is some other way to solve the problem or design alternatives that make it irrelevant.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You don’t have to do anything. PostgreSQL will automatically use TOAST on values larger than 8 kB.

    From http://www.postgresql.org/docs/9.1/static/storage-toast.html

    PostgreSQL uses a fixed page size (commonly 8 kB), and does not allow tuples to span multiple pages. Therefore, it is not possible to store very large field values directly. To overcome this limitation, large field values are compressed and/or broken up into multiple physical rows. This happens transparently to the user, with only small impact on most of the backend code. The technique is affectionately known as TOAST (or “the best thing since sliced bread”).

    PostgreSQL caching is also done at the page level so TOAST does not have to be cached with the rest of the row (http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf).

    • 0