Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin

From: Noah Misch <noah(at)leadboat(dot)com>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin
Date: 2013-06-08 01:30:58
Message-ID: 20130608013058.GE408429@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-06-08 01:52:00 Re: Last log line for log_temp_files is disassociated with query
Previous Message Josh Berkus 2013-06-07 23:55:13 Re: Last log line for log_temp_files is disassociated with query