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
обсуждение исходный текст
Ответ на Re: Partitioning performance: cache stringToNode() of pg_constraint.ccbin  (Noah Misch <noah@leadboat.com>)
Список 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.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Farina
Дата:
Сообщение: Re: Hard limit on WAL space used (because PANIC sucks)
Следующее
От: Kohei KaiGai
Дата:
Сообщение: Re: RFC: ExecNodeExtender