On 2024-Jan-30, Ashutosh Bapat wrote:
> On Mon, Jan 29, 2024 at 10:43 PM Alvaro Herrera
> wrote:
> > I also added a trivial test for EXPLAIN EXECUTE, which was uncovered,
> > and some other minor stylistic changes.
>
> Thanks. Looks fine to me.
Thanks for looking!
--
Álvaro Herrera
On Mon, Jan 29, 2024 at 10:43 PM Alvaro Herrera wrote:
>
> Okay, so I gave this another look and concluded that I definitely didn't
> like the whole business of having one level open the explain group and
> return outwards whether it had been done so that the other level would
> close it. So I
Okay, so I gave this another look and concluded that I definitely didn't
like the whole business of having one level open the explain group and
return outwards whether it had been done so that the other level would
close it. So I made the code do what I said I thought it should do
(adding a new
On Thu, Jan 18, 2024 at 5:28 PM Alvaro Herrera wrote:
>
> On 2024-Jan-18, Ashutosh Bapat wrote:
>
> > The EXPLAIN output produces something like below
> >explain_filter
> > -
> >Seq Scan on int8_tbl i8
On 2024-Jan-18, Ashutosh Bapat wrote:
> The EXPLAIN output produces something like below
>explain_filter
> -
>Seq Scan on int8_tbl i8 (cost=N.N..N.N rows=N width=N)
> Planning:
> Memory: used=N bytes,
On Thu, Jan 18, 2024 at 4:42 PM Alvaro Herrera wrote:
>
> On 2024-Jan-18, Ashutosh Bapat wrote:
>
> Hmm ... TBH I don't like the "showed_planning" thing very much, but if
> we need to conditionalize the printing of "Planning:" on whether we
> print either of buffers or memory, maybe there's no
On 2024-Jan-18, Ashutosh Bapat wrote:
Hmm ... TBH I don't like the "showed_planning" thing very much, but if
we need to conditionalize the printing of "Planning:" on whether we
print either of buffers or memory, maybe there's no way around something
like what you propose.
However, I don't
On Tue, Jan 16, 2024 at 8:19 PM Ashutosh Bapat
wrote:
>
> Using a boolean return and moving es->indent-- outside of
> show_buffer_usage would be less elegant.
>
I went ahead with this option so as not to break backward
compatibility in any manner. Attached patch 0002 has the code and
expected
Replying to both Alvaro and Abhijit in this email.
On Fri, Jan 12, 2024 at 10:22 PM Alvaro Herrera wrote:
>
> I think this patch is mostly OK and decided to use it to test something
> else. In doing so I noticed one small thing that bothers me: if
> planning uses buffers, and those were
At 2024-01-12 17:52:27 +0100, alvhe...@alvh.no-ip.org wrote:
>
> I think this patch is mostly OK
(After the last few rounds of changes, it looks fine to me too.)
> Planning:
>Buffers: shared hit=120 read=30
>Memory: used=67944 bytes allocated=73728 bytes
> Planning Time: 0.892 ms
>
>
I think this patch is mostly OK and decided to use it to test something
else. In doing so I noticed one small thing that bothers me: if
planning uses buffers, and those were requested to be reported, we get
something like this at the end of the explain
Planning:
Buffers: shared hit=120
Forgot to attach patch. Here it is
On Mon, Dec 18, 2023 at 12:55 PM Ashutosh Bapat
wrote:
>
> On Sun, Dec 17, 2023 at 10:31 PM Alvaro Herrera
> wrote:
> >
> > OK, I propose the following further minor tweaks. (I modified the docs
> > following the wording we have for COSTS and BUFFERS).
>
>
On Sun, Dec 17, 2023 at 10:31 PM Alvaro Herrera wrote:
>
> OK, I propose the following further minor tweaks. (I modified the docs
> following the wording we have for COSTS and BUFFERS).
LGTM. Included in the attached patch.
>
> There are two things that still trouble me a bit. First, we
OK, I propose the following further minor tweaks. (I modified the docs
following the wording we have for COSTS and BUFFERS).
There are two things that still trouble me a bit. First, we assume that
the planner is using an AllocSet context, which I guess is true, but if
somebody runs the planner
On Wed, Dec 13, 2023 at 1:41 AM Alvaro Herrera wrote:
>
> I would replace the text in explain.sgml with this:
>
> + Include information on memory consumption by the query planning phase.
> + This includes the precise amount of storage used by planner in-memory
> + structures, as
On 2023-Dec-12, Alvaro Herrera wrote:
> I would replace the text in explain.sgml with this:
>
> + Include information on memory consumption by the query planning phase.
> + This includes the precise amount of storage used by planner in-memory
> + structures, as well as overall
I would replace the text in explain.sgml with this:
+ Include information on memory consumption by the query planning phase.
+ This includes the precise amount of storage used by planner in-memory
+ structures, as well as overall total consumption of planner memory,
+
On Mon, Dec 11, 2023 at 2:06 PM jian he wrote:
>
> On Mon, Dec 4, 2023 at 3:24 PM Ashutosh Bapat
> wrote:
> >
> > On Fri, Dec 1, 2023 at 8:27 AM Andrei Lepikhov
> > wrote:
> > >
> > > On 30/11/2023 18:40, Alvaro Herrera wrote:
> > > > Well, SUMMARY is enabled by default with ANALYZE, and I'd
On Mon, Dec 4, 2023 at 3:24 PM Ashutosh Bapat
wrote:
>
> On Fri, Dec 1, 2023 at 8:27 AM Andrei Lepikhov
> wrote:
> >
> > On 30/11/2023 18:40, Alvaro Herrera wrote:
> > > Well, SUMMARY is enabled by default with ANALYZE, and I'd rather not
> > > have planner memory consumption displayed by
On Fri, Dec 1, 2023 at 8:27 AM Andrei Lepikhov
wrote:
>
> On 30/11/2023 18:40, Alvaro Herrera wrote:
> > Well, SUMMARY is enabled by default with ANALYZE, and I'd rather not
> > have planner memory consumption displayed by default with all EXPLAIN
> > ANALYZEs. So yeah, I still think this
On 30/11/2023 18:40, Alvaro Herrera wrote:
Well, SUMMARY is enabled by default with ANALYZE, and I'd rather not
have planner memory consumption displayed by default with all EXPLAIN
ANALYZEs. So yeah, I still think this deserves its own option.
But let's hear others' opinions on this point.
On 2023-Nov-30, Ashutosh Bapat wrote:
> Hi Alvaro,
> Thanks for the review and the edits. Sorry for replying late.
>
> On Tue, Nov 21, 2023 at 11:56 PM Alvaro Herrera
> wrote:
> >
> > I gave this a quick look. I think the usefulness aspect is already
> > established in general terms; the bit
Hi Alvaro,
Thanks for the review and the edits. Sorry for replying late.
On Tue, Nov 21, 2023 at 11:56 PM Alvaro Herrera wrote:
>
> I gave this a quick look. I think the usefulness aspect is already
> established in general terms; the bit I'm not so sure about is whether
> we want it enabled by
I gave this a quick look. I think the usefulness aspect is already
established in general terms; the bit I'm not so sure about is whether
we want it enabled by default. For many cases it'd just be noise.
Perhaps we want it hidden behind something like "EXPLAIN (MEMORY)" or
such, particularly
>
>
> David challenged something at the begining, but IIUC he also agree the
> value of patch 01 as the previous statement after discussion. Since the patch
> is mild itself, so I will mark this commitfest entry as "Ready for committer".
> Please correct me if anything is wrong.
>
Thanks Andy.
Hi Ashutosh,
On Fri, Sep 22, 2023 at 5:56 PM Ashutosh Bapat
wrote:
> Hi Andy,
> Thanks for your feedback.
>
> On Fri, Sep 22, 2023 at 8:22 AM Andy Fan wrote:
> >
> > 1). The commit message of patch 1 just says how it does but doesn't
> > say why it does. After reading through the discussion, I
Hi Andy,
Thanks for your feedback.
On Fri, Sep 22, 2023 at 8:22 AM Andy Fan wrote:
>
> 1). The commit message of patch 1 just says how it does but doesn't
> say why it does. After reading through the discussion, I suggest making
> it clearer to others.
>
> ...
> After the planning is done, it
Hi Ashutosh,
Thanks for the patch!
I think the reason why others are not excited about this is because the
benefit is not clear enough to them after the first glance and plus the
chosen wolds "Planning Memory: used " is still confusing for different
people. I admit it is clear to you absolutely,
Using your patch I found out one redundant memory usage in the planner [1]. It
can be interesting as an example of how this patch can detect problems.
[1] Optimize planner memory consumption for huge arrays
Sorry for the late reply. I was working on David's suggestion.
Here's a response to your questions and also a new set of patches.
On Tue, Aug 22, 2023 at 1:16 PM jian he wrote:
> Hi. I tested it.
> not sure if following is desired behavior. first run with explain,
> then run with
On Mon, Aug 14, 2023 at 3:13 PM Ashutosh Bapat
wrote:
>
> On Mon, Aug 14, 2023 at 8:22 AM Andrey Lepikhov
> wrote:
> >
> > Really, the current approach with the final value of consumed memory
> > smooths peaks of memory consumption. I recall examples likewise massive
> > million-sized arrays or
On Mon, Aug 14, 2023 at 8:22 AM Andrey Lepikhov
wrote:
>
> Really, the current approach with the final value of consumed memory
> smooths peaks of memory consumption. I recall examples likewise massive
> million-sized arrays or reparameterization with many partitions where
> the optimizer
On Mon, Aug 14, 2023 at 5:23 AM David Rowley wrote:
>
> On Thu, 10 Aug 2023 at 20:33, Ashutosh Bapat
> wrote:
> > My point is what's relevant here is how much net memory planner asked
> > for.
>
> But that's not what your patch is reporting. All you're reporting is
> the difference in memory
On 14/8/2023 06:53, David Rowley wrote:
On Thu, 10 Aug 2023 at 20:33, Ashutosh Bapat
wrote:
My point is what's relevant here is how much net memory planner asked
for.
But that's not what your patch is reporting. All you're reporting is
the difference in memory that's *currently* palloc'd
On Thu, 10 Aug 2023 at 20:33, Ashutosh Bapat
wrote:
> My point is what's relevant here is how much net memory planner asked
> for.
But that's not what your patch is reporting. All you're reporting is
the difference in memory that's *currently* palloc'd from before and
after the planner ran. If
On Fri, Aug 11, 2023 at 10:41 AM Andrey Lepikhov
wrote:
> >>
> >
> > 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.
On 10/8/2023 15:33, Ashutosh Bapat wrote:
On Wed, Aug 9, 2023 at 8:56 PM David Rowley wrote:
On Thu, 10 Aug 2023 at 03:12, Ashutosh Bapat
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,
Hi David,
On Wed, Aug 9, 2023 at 8:09 PM Ashutosh Bapat
wrote:
>
> I need to just make sure that the Planning Memory is reported with SUMMARY ON.
>
The patch reports planning memory in EXPLAIN without ANALYZE when SUMMARY = ON.
#explain (summary on) select * from a, b where a.c1 = b.c1 and a.c1
On Wed, Aug 9, 2023 at 8:56 PM David Rowley wrote:
>
> On Thu, 10 Aug 2023 at 03:12, Ashutosh Bapat
> wrote:
> > Thinking more about it, I think memory used is the only right metrics.
> > It's an optimization in MemoryContext implementation that malloc'ed
> > memory is not freed when it is
On Thu, 10 Aug 2023 at 03:12, Ashutosh Bapat
wrote:
> Thinking more about it, I think memory used is the only right metrics.
> It's an optimization in MemoryContext implementation that malloc'ed
> memory is not freed when it is returned using free().
I guess it depends on the problem you're
On Wed, Aug 9, 2023 at 8:09 PM Ashutosh Bapat
wrote:
>
> Hi David,
> Replying to your comments on this thread.
>
> > On Tue, Aug 8, 2023 at 11:40 AM Ashutosh Bapat
> > wrote:
> >>
> >> Hi All,
> >> I have been looking at memory consumed when planning a partitionwise join
> >> [1], [2] and [3].
Hi David,
Replying to your comments on this thread.
> On Tue, Aug 8, 2023 at 11:40 AM Ashutosh Bapat
> wrote:
>>
>> Hi All,
>> I have been looking at memory consumed when planning a partitionwise join
>> [1], [2] and [3]. I am using the attached patch to measure the memory
>> consumption. The
42 matches
Mail list logo
