title: Query efficiency of timestamp-partitioned tables using CURRENT_TIMESTAMP
body: <p>Given the following table partitioning under PostgreSQL 9.0.3:</p>
  
  <pre><code>CREATE TABLE records (
    ts TIMESTAMP,
    ...
  );
  
  CREATE TABLE records_2010 (
    CHECK (ts &gt;= '2010-01-01 00:00:00' AND ts &lt; '2011-01-01 00:00:00')
  ) INHERITS (records);
  
  CREATE TABLE records_2011 (
    CHECK (ts &gt;= '2011-01-01 00:00:00' AND ts &lt; '2012-01-01 00:00:00')
  ) INHERITS (records);
  </code></pre>
  
  <p>I expected the following SELECT queries to have the same EXPLAINed plan, consulting only "records" and "records_2011", but they differ:</p>
  
  <pre><code>BEGIN;
  -- Assume CURRENT_TIMESTAMP is 9 a.m. on 5 March 2011
  SELECT * FROM records WHERE ts &gt;= '2011-03-05 09:00:00'; -- scans 2 tables
  SELECT * FROM records WHERE ts &gt;= CURRENT_TIMESTAMP;     -- scans all 3 tables
  COMMIT;
  </code></pre>
  
  <p>Given that CURRENT_TIMESTAMP returns a constant value for the duration of its enclosing transactions, <strong>why doesn't the query with CURRENT_TIMESTAMP take advantage of Postgres' partitioning and only scan two tables?</strong></p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>This isn't possible right now, but it is recognized as an area to improve.  PostgreSQL 9.1 may <a href="http://archives.postgresql.org/pgsql-performance/2010-03/msg00080.php" rel="nofollow">address this behavior in the query executor</a>.</p>