Re: plan time of MASSIVE partitioning ...
От
PostgreSQL - Hans-Jürgen Schönig
Тема
Re: plan time of MASSIVE partitioning ...
Дата
Msg-id
BA9ED250-AB20-4AFC-9905-80F43E210C80@cybertec.at
Ответ на
Re: plan time of MASSIVE partitioning ... (Tom Lane)
Список
Дерево обсуждения
plan time of MASSIVE partitioning ... PostgreSQL - Hans-Jürgen Schönig<postgres@cybertec.at>
Re: plan time of MASSIVE partitioning ... Stephen Frost <sfrost@snowman.net>
Re: plan time of MASSIVE partitioning ... PostgreSQL - Hans-Jürgen Schönig<postgres@cybertec.at>
Re: plan time of MASSIVE partitioning ... Stephen Frost <sfrost@snowman.net>
Re: plan time of MASSIVE partitioning ... Tom Lane <tgl@sss.pgh.pa.us>
Re: plan time of MASSIVE partitioning ... PostgreSQL - Hans-Jürgen Schönig<postgres@cybertec.at>
Re: plan time of MASSIVE partitioning ... Robert Haas <robertmhaas@gmail.com>
On Sep 3, 2010, at 4:40 PM, Tom Lane wrote: > PostgreSQL - Hans-Jürgen Schönig writes: >> imagine a system with, say, 1000 partitions (heavily indexed) or so. the time taken by the planner is already fairly heavy in this case. > > As the fine manual points out, the current scheme for managing > partitioned tables isn't intended to scale past a few dozen partitions. > > I think we'll be able to do better when we have an explicit > representation of partitioning, since then the planner won't > have to expend large amounts of effort reverse-engineering knowledge > about how an inheritance tree is partitioned. Before that happens, > it's not really worth the trouble to worry about such cases. > > regards, tom lane > thank you ... - the manual is clear here but we wanted to see if there is some reasonably low hanging fruit to get around this. it is no solution but at least a clear statement ... many thanks, hans -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de
В списке pgsql-hackers по дате отправления
От: Tom Lane
Дата: