Re: Report planning memory in EXPLAIN ANALYZE

From: Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Report planning memory in EXPLAIN ANALYZE
Date: 2023-08-11 05:11:21
Message-ID: af3bc526-4f3b-67dd-02e4-f04129b2d743@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/8/2023 15:33, Ashutosh Bapat wrote:
> On Wed, Aug 9, 2023 at 8:56 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>>
>> On Thu, 10 Aug 2023 at 03:12, Ashutosh Bapat
>> <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>> I guess it depends on the problem you're trying to solve. I had
>> thought you were trying to do some work to reduce the memory used by
>> the planner, so I imagined you wanted this so you could track your
>> progress and also to help ensure we don't make too many mistakes in
>> the future which makes memory consumption worse again.
>> Another way we might go about reducing planner memory is to make
>> changes to the allocators themselves. For example, aset rounds up to
>> the next power of 2. If we decided to do something like add more
>> freelists to double the number so we could add a mid-way point
>> freelist between each power of 2, then we might find it reduces the
>> planner memory by, say 12.5%. If we just tracked what was consumed by
>> palloc() that would appear to save us nothing, but it might actually
>> save us several malloced blocks.
>>
>
> This won't just affect planner but every subsystem of PostgreSQL, not
> just planner, unless we device a new context type for planner.
>
> My point is what's relevant here is how much net memory planner asked
> for. Internally how much memory PostgreSQL allocated seems relevant
> for the memory context infra as such but not so much for planner
> alone.
>
> If you think that memory allocated is important, I will add both used
> and (net) allocated memory to EXPLAIN output.
As a developer, I like having as much internal info in my EXPLAIN as
possible. But this command is designed mainly for users, not core
developers. The size of memory allocated usually doesn't make sense for
users. On the other hand, developers can watch it easily in different
ways, if needed. So, I vote for the 'memory used' metric only.

The patch looks good, passes the tests.

--
regards,
Andrey Lepikhov
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2023-08-11 05:13:48 Re: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Noah Misch 2023-08-11 02:44:20 Re: Cirrus-ci is lowering free CI cycles - what to do with cfbot, etc?