performance using table partitions in Postgres 8.2.6

Hi. I am looking for information about using table partitions in Postgres,
in particular w.r.t. performance when querying a partitioned table.

I implemented table partitioning following the documentation, which
is quite good and easy to follow (Chapter 5.9). I am doing some
testing, so at this point my test dataset has 1M records; in the table,
each row will have an autoincrement integer index, two numerics,
one integer (DMID), and one smallint.

I created five master tables and created a different number of
partitions for each one (2, 4, 8, 16, 32). I am using a range partition
for the integer, DMID, which represents a file index. The values of
DMID range from 0 to 180360. I also create and index for DMID.

I don't understand the timing results that I am getting. I got these
times by averaging the results of querying the database from within
a loop in a Perl script:

no. of partitions constraint_exclusion off constraint_exclusion on
2 0.597 ms 0.427 ms
4 0.653 ms 0.414 ms
8 0.673 ms 0.654 ms
16 1.068 ms 1.014 ms
32 2.301 ms 1.537 ms

I expected that the query time would decrease as the number of
partitions increases, but that's not what I am seeing. I get better results
(0.29 ms) if I simply index DMID and don't use the partitions.

When I run "explain analyze"on a query, the results (with and without
constraint_exclusion set) indicate that fewer partitions are being scanned
when constraint_exclusion is set to on.

I am testing table partitioning in Postgres against table partitioning
using MySQL. The results for MySQL make sense: more partitions,
faster query times.

The underlying application is a file index. It is expected that groups
of files in selected ranges of DMID values will be accessed more
often, but this is not the key implementation issue.

This is basically a "write once, read often" database. We expect that
the database will grow to 50M records in a few years, and I thought
that using range partitions for the DMID value might decrease the
query time.

Should I be using many more partitions? Am I expecting too much in
terms of performance when using partitions? Do these results point to
some obvious implementation error?

Thank you for any help/suggestions you can give.

Janet Jacobsen

--
Janet Jacobsen
NERSC Analytics/HPCRD Visualization Group
Lawrence Berkeley National Laboratory