On Fri, Sep 5, 2014 at 10:31 AM, Cal Heldenbrand <cal@fbsdata.com> wrote:
explain analyze select time,event from logins where username='bob' and hash='1234' and time > current_date - interval '1 week';
Result (cost=0.00..765.11 rows=1582 width=14) -> Append (cost=0.00..765.11 rows=1582 width=14) -> Seq Scan on logins (cost=0.00..0.00 rows=1 width=66) Filter: (((username)::text = 'bob'::text) AND ((hash)::text = '1234'::text) AND ("time" > (('now'::text)::date - '7 days'::interval))) -> Index Scan using logins_20100501_username_time on logins_20100501 logins (cost=0.01..0.48 rows=1 width=14) ...
This shows that it's attempting to run the query against all of my 1500 child tables.
I believe the problem is that the planner (which does the partition pruning) is not willing to materialize the value of current_date, so it can't use a specific value to prune partitions. After all, the date might change between the planner and the executor, if you leave the plan open for a long time, or make the call very close to midnight.
You will probably have to select the current_date (or get it from your system, or cron, or whoever triggers the script), and then hardcode it into the query.