Re: Parent/child context relation in pg_get_backend_memory_contexts()

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parent/child context relation in pg_get_backend_memory_contexts()
Date: 2024-01-10 06:37:01
Message-ID: f94acf68cee0483aade20a219f127a6c@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-01-03 20:40, Melih Mutlu wrote:
> Hi,
>
> Thanks for reviewing. Please find the updated patch attached.
>
> torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, 4 Ara 2023 Pzt, 07:43
> tarihinde şunu yazdı:
>
>> I reviewed v3 patch and here are some minor comments:
>>
>>> + <row>
>>> + <entry role="catalog_table_entry"><para
>>> role="column_definition">
>>> + <structfield>path</structfield> <type>int4</type>
>>
>> Should 'int4' be 'int4[]'?
>> Other system catalog columns such as pg_groups.grolist distinguish
>> whther the type is a array or not.
>
> Right! Done.
>
>>> + Path to reach the current context from TopMemoryContext.
>>> Context ids in
>>> + this list represents all parents of the current context.
>> This
>>> can be
>>> + used to build the parent and child relation.
>>
>> It seems last "." is not necessary considering other explanations
>> for
>> each field end without it.
>
> Done.
>
>> + const char *parent, int level, int
>> *context_id,
>> + List *path, Size
>> *total_bytes_inc_chidlren)
>>
>> 'chidlren' -> 'children'
>
> Done.
>
>> + elog(LOG, "pg_get_backend_memory_contexts called");
>>
>> Is this message necessary?
>
> I guess I added this line for debugging and then forgot to remove. Now
> removed.
>
>> There was warning when applying the patch:
>>
>> % git apply
>>
> ../patch/pg_backend_memory_context_refine/v3-0001-Adding-id-parent_id-into-pg_backend_memory_contex.patch
>>
>>
> ../patch/pg_backend_memory_context_refine/v3-0001-Adding-id-parent_id-into-pg_backend_memory_contex.patch:282:
>>
>> trailing whitespace.
>> select count(*) > 0
>>
>>
> ../patch/pg_backend_memory_context_refine/v3-0001-Adding-id-parent_id-into-pg_backend_memory_contex.patch:283:
>>
>> trailing whitespace.
>> from contexts
>> warning: 2 lines add whitespace errors.
>
> Fixed.
>
> Thanks,--
>
> Melih Mutlu
> Microsoft

Thanks for updating the patch.

> + <row>
> + <entry role="catalog_table_entry"><para
> role="column_definition">
> + <structfield>context_id</structfield> <type>int4</type>
> + </para>
> + <para>
> + Current context id. Note that the context id is a temporary id
> and may
> + change in each invocation
> + </para></entry>
> + </row>
> +
> + <row>
> + <entry role="catalog_table_entry"><para
> role="column_definition">
> + <structfield>path</structfield> <type>int4[]</type>
> + </para>
> + <para>
> + Path to reach the current context from TopMemoryContext.
> Context ids in
> + this list represents all parents of the current context. This
> can be
> + used to build the parent and child relation
> + </para></entry>
> + </row>
> +
> + <row>
> + <entry role="catalog_table_entry"><para
> role="column_definition">
> + <structfield>total_bytes_including_children</structfield>
> <type>int8</type>
> + </para>
> + <para>
> + Total bytes allocated for this memory context including its
> children
> + </para></entry>
> + </row>

These columns are currently added to the bottom of the table, but it may
be better to put semantically similar items close together and change
the insertion position with reference to other system views. For
example,

- In pg_group and pg_user, 'id' is placed on the line following 'name',
so 'context_id' be placed on the line following 'name'
- 'path' is similar with 'parent' and 'level' in that these are
information about the location of the context, 'path' be placed to next
to them.

If we do this, orders of columns in the system view should be the same,
I think.

> + ListCell *lc;
> +
> + length = list_length(path);
> + datum_array = (Datum *) palloc(length * sizeof(Datum));
> + length = 0;
> + foreach(lc, path)
> + {
> + datum_array[length++] = Int32GetDatum(lfirst_int(lc));
> + }

14dd0f27d have introduced new macro foreach_int.
It seems to be able to make the code a bit simpler and the commit log
says this macro is primarily intended for use in new code. For example:

| int id;
|
| length = list_length(path);
| datum_array = (Datum *) palloc(length * sizeof(Datum));
| length = 0;
| foreach_int(id, path)
| {
| datum_array[length++] = Int32GetDatum(id);
| }

--
Regards,

--
Atsushi Torikoshi
NTT DATA Group Corporation

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sutou Kouhei 2024-01-10 06:40:28 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message Masahiko Sawada 2024-01-10 06:33:22 Re: Make COPY format extendable: Extract COPY TO format implementations