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 по дате отправления: