Why should such a simple query over indexed columns be so slow? - Mailing list pgsql-performance

SELECT private, COUNT(block_id) FROM blocks WHERE created > 'yesterday' AND shared IS FALSE GROUP BY private

What confuses me is that though this is a largish table (millions of rows) with constant writes, the query is over indexed columns of types timestamp and boolean so I would expect it to be very fast. The clause where created > 'yesterday' is there mostly to speed it up, but apparently it doesn't help much.  

Here's the Full Table and Index Schema:

CREATE TABLE blocks
(
  block_id character(24) NOT NULL,
  user_id character(24) NOT NULL,
  created timestamp with time zone,
  locale character varying,
  shared boolean,
  private boolean,
  moment_type character varying NOT NULL,
  user_agent character varying,
  inserted timestamp without time zone NOT NULL DEFAULT now(),
  networks character varying[],
  lnglat point,
  CONSTRAINT blocks_pkey PRIMARY KEY (block_id )
)

WITH (
  OIDS=FALSE
);

CREATE INDEX blocks_created_idx
  ON blocks
  USING btree
  (created  DESC NULLS LAST);

CREATE INDEX blocks_lnglat_idx
  ON blocks
  USING gist
  (lnglat );

CREATE INDEX blocks_networks_idx
  ON blocks
  USING btree
  (networks );

CREATE INDEX blocks_private_idx
  ON blocks
  USING btree
  (private );

CREATE INDEX blocks_shared_idx
  ON blocks
  USING btree
  (shared );

Here's the results from EXPLAIN ANALYZE:

"HashAggregate  (cost=156619.01..156619.02 rows=2 width=26) (actual time=43131.154..43131.156 rows=2 loops=1)"
"  ->  Seq Scan on blocks  (cost=0.00..156146.14 rows=472871 width=26) (actual time=274.881..42124.505 rows=562888 loops=1)"
"        Filter: ((shared IS FALSE) AND (created > '2012-01-29 00:00:00+00'::timestamp with time zone))"
"Total runtime: 43131.221 ms"