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

Поиск
Список
Период
Сортировка
Искать
От
Amit Kapila
Тема
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin
Дата
Msg-id
005001ce6348$31710a50$94531ef0$@kapila@huawei.com
Ответ на
Список
Дерево обсуждения
Partitioning performance: cache stringToNode() of pg_constraint.ccbin Noah Misch <noah@leadboat.com>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Amit Kapila <amit.kapila@huawei.com>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Bruce Momjian <bruce@momjian.us>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Noah Misch <noah@leadboat.com>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Bruce Momjian <bruce@momjian.us>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Robert Haas <robertmhaas@gmail.com>
Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin Noah Misch <noah@leadboat.com>
Re: [HACKERS] Partitioning performance: cache stringToNode() of pg_constraint.ccbin Hannu Krosing <hkrosing@gmail.com>
Re: [HACKERS] Partitioning performance: cache stringToNode() of pg_constraint.ccbin Hannu Krosing <hkrosing@gmail.com>
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.



В списке pgsql-hackers по дате отправления
От: Daniel Farina
Дата:
От: Kohei KaiGai
Дата:
Сообщение: Re: RFC: ExecNodeExtender
FAQ