[GENERAL] Are partitions getting pruned?

[Robert Klaus]

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