Re: Table partitioning

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(at)gmail(dot)com]
Sent: Wednesday, April 26, 2006 2:33 PM
To: Benjamin Krajmalnik
Cc: pgsql-admin(at)postgresql(dot)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