Are partitions getting pruned?

Postgres 8.4.9 on CentOS

I partitioned some tables over the weekend by month using a date field as
the partitioning column. Table inheritance was used and all indexes on the
parent were created on the partitions. constraint_exclustion = partition.

My question is, are partitions really getting pruned or are locks showing
up just due to inheritance.

When I run an explain of the query it shows partition pruning.

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'

Result (cost=0.00..154563.67 rows=99468 width=210) (actual
time=557.634..2174.804 rows=104042 loops=1)

-> Append (cost=0.00..154563.67 rows=99468 width=210) (actual
time=557.631..2109.153 rows=104042 loops=1)

-> Seq Scan on daily_nbr_list (cost=0.00..15.10 rows=2 width=209)
(actual time=0.000..0.000 rows=0 loops=1)

Filter: ((item_date = '2013-03-17'::date) AND ((market)::text
= 'Chicago'::text))

-> Bitmap Heap Scan on daily_nbr_list*_201303* daily_nbr_list
(cost=2844.72..154548.57
rows=99466 width=210) (actual time=557.629..2098.579 rows=104042 loops=1)

Recheck Cond: (item_date = '2013-03-17'::date)

Filter: ((market)::text = 'Chicago'::text)

-> Bitmap Index Scan on daily_nbr_list_idx*_201303*
(cost=0.00..2819.86
rows=152412 width=0) (actual time=167.538..167.538 rows=153963 loops=1)

Index Cond: (item_date = '2013-03-17'::date)

Total runtime: 2181.130 ms

However, when I run the query and view the locks it’s using it shows all
partitions having locks on them.

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201206; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201207; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201208; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201209; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201210; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201211; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201212; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201301; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201302; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201303; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201304; AccessShareLock

select * from voice.daily_nbr_list where item_date = '2013-03-17' and
market = 'Chicago'; voice.daily_nbr_list_201305; AccessShareLock

I noticed row exclusive locks being held on all partitions for procedure
calls that update the data.

Thanks,
Robert