Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin
От | Noah Misch |
---|---|
Тема | Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin |
Дата | |
Msg-id | 20130608013058.GE408429@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Partitioning performance: cache stringToNode() of pg_constraint.ccbin (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
On Fri, Jun 07, 2013 at 11:58:14AM +0530, Amit Kapila wrote: > So the memory increase number's would like: > > Example for 64-bit m/c > In database, there are 100 tables, each having 2 constraints and 30 live > connections > > Size increase = no. of tables * size of (Node*) * number of constraints * > no. of live sessions > = 100 * 8 * 2 * 30 > = 46.8K That's the increase when nothing consults the constraints. Upon first use of a particular constraint, one cache can easily grow by a few hundred bytes. > So if such a memory increase seems reasonable, then I think it would be > really beneficial for the load of data in inherited tables. I agree that the memory usage is the main downside. We already do similar caching for index expressions and for rules, incidentally. On that note, I see that the patch does not make RelationDestroyRelation() correctly free the newly-cached data. Will fix. -- Noah Misch EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: