Search Postgresql Archives

Performance impact of hundreds of partitions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux