Actually, right now there is no data in those partitions.
All of the data is currently in the parent table (I have not yet created the trigger which will route the data to the correct partition).
I just found to items intriguing – first, that the indices and other properties other than the field definition were not inherited (is this how this is supposed to work?), and second, that PG first retrieves the entire result set and then limits it (or at least that appear to be how it is working).
If the order by clause were an expression, I can understand where it would have to first retrieve the entire resultset and then limit it. However, when we are dealing with an order by clause running on an index or primary key, I would figure that it would only retrieve the number of rows limited, or if an offset is specified then go to the offset and only process the “limit” number of rows.
From: Chris Hoover [mailto:revoohc@gmail.com]
Sent: Wednesday, April 26, 2006 2:33 PM
To: Benjamin Krajmalnik
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Tale partitioning
Each of the partition tables needs it's own set of indexes. Build them, and see if the does not fix your performance issues. Also, be sure you turned on the constraint_exclusion parameter, and each table (other than the "master") has an constraint on it that is unique.
HTH,
Chris