Performance impact of hundreds of partitions

Поиск
Список
Период
Сортировка
От Leonardo F
Тема Performance impact of hundreds of partitions
Дата
Msg-id 644679.46887.qm@web29018.mail.ird.yahoo.com
обсуждение исходный текст
Ответы Re: Performance impact of hundreds of partitions
Re: Performance impact of hundreds of partitions
Список pgsql-general
Hi,

increasing shared_buffers has improved *a lot* the number of inserts/second,
so my "problem" [1] is fixed.

But now I'm worried because of the sentence (Tom Lane):

"The partitioning code isn't designed to scale beyond a few dozen partitions"

Is it mainly a planning problem or an execution time problem?

I did a (very quick) test with 3000 empty partitions, and it took 0.5 secs to do
the planning for a simple select with a very simple where condition.
With 300 partitions, planning takes about 30ms.

That's fine for my case, as I don't expect more than 300 partitions; and I could
actually wait for .5 secs more if that helps with such large tables, and I won't
be doing joins.


So: the "scaling" problem would be more evident in case joins were taken into
account? Or there's something else I didn't get?



[1] http://archives.postgresql.org/pgsql-general/2010-04/msg00611.php





В списке pgsql-general по дате отправления:

Предыдущее
От: Leonardo F
Дата:
Сообщение: Re: performance problems inserting random vals in index
Следующее
От: A B
Дата:
Сообщение: Re: Database viewpoint of subject - Sending e-mails from database table with Cronjob