title: PostgreSQL temporary table cache in memory?
body: <p><strong>Context</strong>:</p>
  
  <p>I want to store some temporary results in some temporary tables. These tables may be reused in several queries that may occur close in time, but at some point the evolutionary algorithm I'm using may not need some old tables any more and keep generating new tables. There will be several queries, possibly concurrently, using those tables. Only one user doing all those queries. I don't know if that clarifies everything about sessions and so on, I'm still uncertain about how that works.</p>
  
  <p><strong>Objective</strong>:</p>
  
  <p>What I would like to do is to create temporary tables (if they don't exist already), store them on memory as far as that is possible and if at some point there is not enough memory, delete those that would be committed to the HDD (I guess those will be the least recently used).</p>
  
  <p><strong>Examples</strong>:</p>
  
  <p>The client will be doing queries for <a href="https://stackoverflow.com/questions/8871426/how-to-calculate-an-exponential-moving-average-on-postgres">EMAs</a> with different parameters and an aggregation of them with different coefficients, each individual may vary in terms of the coefficients used and so the parameters for the EMAs may repeat as they are still in the gene pool, and may not be needed after a while. There will be similar queries with more parameters and the genetic algorithm will find the right values for the parameters.</p>
  
  <p><strong>Questions</strong>:</p>
  
  <ul>
  <li>Is that what "on commit drop" means? I've seen descriptions about
  sessions and transactions but I don't really understand those
  concepts. Sorry if the question is stupid.</li>
  <li>If it is not, do you know about any simple way to get Postgres to do
  this? </li>
  </ul>
  
  <p><strong>Workaround</strong>:</p>
  
  <p>In the worst case I should be able to make a guesstimation about how many tables I can keep on memory and try to implement the LRU by myself, but it's never going to be as good as what Postgres could do.</p>
  
  <p>Thank you very much.</p>