Re: I don't understand that EXPLAIN PLAN timings

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Jean-Christophe Boggio <postgresql(at)thefreecat(dot)org>
Cc: pgsql-performance(at)lists(dot)postgresql(dot)org
Subject: Re: I don't understand that EXPLAIN PLAN timings
Date: 2024-01-26 04:46:19
Message-ID: CAApHDvoj-M5HZzYuOwuuzVn=OvD4t9q8rPFDAhzDEKYfb5S03A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, 26 Jan 2024 at 17:23, Jean-Christophe Boggio
<postgresql(at)thefreecat(dot)org> wrote:
> Let me know if I can do anything to provide you with more useful
> benchmark. The DB is still very small so it is easy to do tests.

What I was looking to find out was if there was some enable_* GUC that
you could turn off that would make the unaccounted time that you were
complaining about go away.

Because it seems when you reduce work_mem this unaccounted for time
goes away, it makes me think that some executor node is allocating a
load of memory during executor startup. I was hoping to find out
which node is the offending one by the process of elimination.

Are you still seeing this unaccounted for time with your notebook?
i.e. the relatively high "Execution Time" reported by EXPLAIN ANALYZE
and low total actual execution time on the plan's top-level node.

I probably didn't need to mention the planning time as it seems
unlikely that disabling an enable* GUC would result in increased
planning time. However, it does not seem impossible that that *could*
happen.

David

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Pavlos Kallis 2024-01-30 09:40:19 Slow query in table where many rows were deleted. VACUUM FULL fixes it
Previous Message Jean-Christophe Boggio 2024-01-26 04:22:58 Re: I don't understand that EXPLAIN PLAN timings