Search Postgresql Archives

Re: Performance impact of hundreds of partitions

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

 



Leonardo F wrote:

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

I have here a database with a table partitioned across 400 sub-tables.

I'm using a trigger-based solution with constraint exclusion. The thing that takes the longest is planning queries. I made THAT problem just go away for the most part by using cached queries (only works within the same database connection, but thats no problem for me).

I also tried a rule-based partitioning, that indeed breaks down quickly performance wise.

Also, the trigger is a ON INSERT AND UPDATE, and only on the main table. If your main insert/update process knows into which partition to insert, you can speed that up even more; while still beeing able to use the automated partitioning for everything else.

LG
Rene

--
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