Tom Lane wrote:
"michael McMaster" <[EMAIL PROTECTED]> writes:
I intend on creating a view over a large number of tables (possibly > 1000).
Better rethink that plan ... PG's current partitioning support doesn't
scale that high, and filing bugs claiming it's a memory leak isn't
going to make it do so.
regards, tom lane
I modified the views to mimic the CHECK constraints on the partitioned
tables.
ie CREATE VIEW a_view AS select * from a_table where dtstart between <x>
and <y>
UNION ALL ...
The query plans generated weren't quite as good, but use an
insignificant amount of memory, and are still reasonably fast. This
solution is an acceptable trade off at the moment.
I still think the memory usage issue is a bug, as there are alternative
plans that show Postgres -does- scale that high. I had a quick look
through the code and I suspect that table inheritance wouldn't have this
issue. I'll test inheritance and report my findings.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
