> Are you selecting directly from the child table, or from the parent
> table with constraint_exclusion turned on?
the problem was when selecting from the parent table, but selecting from
child tables are no problem. As stated in other replies, I only wanted to
know how many rows where in the table in total, it is not a part of the
actual operations of the server.
> But hitting the parent table with no constraining where clause is a
> recipe for disaster. The very reason to use partitioning is so that
> you never have to scan through a single giant table.
So I have found out...
> Anyway, you're heading off into new territory with 55,000 partitions.
Perhaps, but I am only using the child tables for actual operations
though. But I also have a couple of indexes on each child table, so there
is now about 150000 indexes as well.
The intended operations of the server works fine, its the select on the
parent table that fails.
> What is the average size, in MB of one of your partitions? I found
> with my test, there was a point of diminishing returns after 400 or so
> partitions at which point indexes were no longer needed, because the
> average query just seq scanned the partitions it needed, and they were
> all ~ 16 or 32 Megs.
I have no idea, but I suspect about a couple of megabytes each, at least
thats the size of the raw data. then maybe add a couple of megabytes more
for internal stuff.
regards
thomas
