|
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@xxxxxxxxx] 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. |
