From: | Amit Kapila <amit(dot)kapila(at)huawei(dot)com> |
---|---|
To: | "'Noah Misch'" <noah(at)leadboat(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin |
Date: | 2013-06-07 06:28:14 |
Message-ID: | 005001ce6348$31710a50$94531ef0$@kapila@huawei.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, June 07, 2013 2:10 AM Noah Misch wrote:
> On Thu, Jun 06, 2013 at 07:02:27PM +0530, Amit Kapila wrote:
> > On Tuesday, June 04, 2013 12:37 AM Noah Misch wrote:
>
> > This patch can give good performance gain in the scenario described
> by you.
> > Infact I had taken the readings with patch, it shows similar gain.
>
> Thanks for testing.
>
> > This patch would increase the relcache size, as for each constraint
> on table
> > it would increase 4 bytes irrespective of whether that can give
> performance
> > benefit or not.
>
> Yep, sizeof(Node *) bytes.
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
So if such a memory increase seems reasonable, then I think it would be
really beneficial for the load of data in inherited tables.
If no one has objections on this part, then I think this is really useful
patch for PostgreSQL.
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2013-06-07 07:23:45 | Re: RFC: ExecNodeExtender |
Previous Message | Daniel Farina | 2013-06-07 05:41:18 | Re: Hard limit on WAL space used (because PANIC sucks) |