On 2025/05/30 21:43, Jelte Fennema-Nio wrote:
On Fri May 30, 2025 at 1:55 PM CEST, David Rowley wrote:
By my count, those who think we should change log_buffers to true are:
Robert [1], Michael Christofides [2], Fujii [3].
+1 for me on changing the default. It just seems confusing to have
d
On Fri May 30, 2025 at 1:55 PM CEST, David Rowley wrote:
By my count, those who think we should change log_buffers to true are:
Robert [1], Michael Christofides [2], Fujii [3].
+1 for me on changing the default. It just seems confusing to have
different defaults for auto_explain and EXPLAIN. I'
On Thu, 29 May 2025 at 16:28, Fujii Masao wrote:
> I agree with changing the default value of auto_explain.log_buffers to true.
> I think that users who know EXPLAIN ANALYZE includes buffers info in
> the result by default since v18 would expect the buffer info also to
> be included in auto_explai
On 2024/12/14 0:59, Michael Christofides wrote:
> I've pushed the main patch.
Woohoo! And thank you. I've already seen quite a lot of positivity around the
commit on Twitter[1][2][3].
> I'm not planning on pushing the auto_explain.log_buffers default change
unless there's a bit more disc
On Fri, 13 Dec 2024 at 16:59, Michael Christofides
wrote:
>
> > I've pushed the main patch.
>
> Woohoo! And thank you. I've already seen quite a lot of positivity around the
> commit on Twitter[1][2][3].
I wanted to highlight this other patch[1] by Atsushi Torikoshi, which
adds "actual filesyste
> I've pushed the main patch.
Woohoo! And thank you. I've already seen quite a lot of positivity around
the commit on Twitter[1][2][3].
> I'm not planning on pushing the auto_explain.log_buffers default change
unless there's a bit more discussion about it.
Much like Guillaume, I'd also be in fav
On Thu, 12 Dec 2024 at 00:16, David Rowley wrote:
> There were a few places that were missing a BUFFERS OFF as indicated
> by the buildfarm. I've fixed a few of these, but there's at least one
> more in pg_stat_statements's level_tracking.sql. I'm currently running
> a -DRELCACHE_FORCE_RELEASE -DC
Le mer. 11 déc. 2024 à 21:41, Jelte Fennema-Nio a
écrit :
> On Wed, 11 Dec 2024 at 10:38, David Rowley wrote:
> > I've pushed the main patch. I'm not planning on pushing the
> > auto_explain.log_buffers default change unless there's a bit more
> > discussion about it.
>
> FreeBSD CFBot seems bro
On Wed, 11 Dec 2024 at 10:38, David Rowley wrote:
> I've pushed the main patch. I'm not planning on pushing the
> auto_explain.log_buffers default change unless there's a bit more
> discussion about it.
FreeBSD CFBot seems broken on a pg_stat_statements test because of
this change:
https://api.c
Le mer. 11 déc. 2024 à 15:00, jian he a
écrit :
> do we also need to update doc/src/sgml/rules.sgml?
>
> https://www.postgresql.org/docs/current/rules-materializedviews.html
>
Yes, you're right. Here is a fix. (Not a patch with a commit message as I
don't know if David will want to commit everyt
do we also need to update doc/src/sgml/rules.sgml?
https://www.postgresql.org/docs/current/rules-materializedviews.html
Le mer. 11 déc. 2024 à 12:16, David Rowley a écrit :
> On Wed, 11 Dec 2024 at 22:38, David Rowley wrote:
> > I've pushed the main patch. I'm not planning on pushing the
> > auto_explain.log_buffers default change unless there's a bit more
> > discussion about it.
>
> There were a few places that
On Wed, 11 Dec 2024 at 22:38, David Rowley wrote:
> I've pushed the main patch. I'm not planning on pushing the
> auto_explain.log_buffers default change unless there's a bit more
> discussion about it.
There were a few places that were missing a BUFFERS OFF as indicated
by the buildfarm. I've fi
On Wed, 11 Dec 2024 at 01:22, Guillaume Lelarge wrote:
> Le mar. 10 déc. 2024 à 03:57, David Rowley a écrit :
>> I was very close to pushing 0001 today, but will hold off until
>> tomorrow to see if anyone has final comments.
>>
> No more comments. I'm fine with both patches.
Thanks for looking.
Hello,
Le mar. 10 déc. 2024 à 03:57, David Rowley a écrit :
> On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge
> wrote:
> > OK, I'm fine with this. v4 patch attached with one plan showing read,
> written, and dirtied buffers.
>
> Today I spent more time polishing this patch. There were a few cas
On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge wrote:
> OK, I'm fine with this. v4 patch attached with one plan showing read,
> written, and dirtied buffers.
Today I spent more time polishing this patch. There were a few cases
in the docs that displayed EXPLAIN ANALYZE output that you'd not
adj
On Mon, Dec 2, 2024 at 6:42 AM Michael Christofides
wrote:
> Are you mostly seeing query plans that have stumped other people already (eg
> second or third line support), so perhaps seeing more complex plans than the
> average user?
Yes. :-)
--
Robert Haas
EDB: http://www.enterprisedb.com
> v4 patch attached
Thank you Guillaume, and nice work! I tried to see if there was anywhere
else in the documentation that would need updating, but it looks like you
covered everywhere already.
> I'm with Robert in that I've not found the buffer counts to be all that
useful most of the time.
I
On Mon, Nov 25, 2024 at 5:52 PM David Rowley wrote:
> OK, thanks. I likely took your neutrality here in a more positive
> light after reading the 4-year-old message at [1]. That probably
> wasn't the right thing to do.
Yeah, I think my view has wavered over time. Probably when I wrote
that messag
> On 20 Nov 2024, at 22:22, David Rowley wrote:
>
> On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge
> wrote:
>> OK, I'm fine with this. v4 patch attached with one plan showing read,
>> written, and dirtied buffers.
>
> I think this might be a good time for anyone out there who is against
> tu
David Rowley writes:
> On Tue, 26 Nov 2024 at 12:12, Tom Lane wrote:
>> I'm kind of -0.5, but I'd not bothered to vote because it was
>> pretty clear what the result was going to be.
> Just so I can properly understand, how much of the -0.5 is "don't like
> the idea" vs "rather make changes to w
On Tue, 26 Nov 2024 at 12:12, Tom Lane wrote:
> I'm kind of -0.5, but I'd not bothered to vote because it was
> pretty clear what the result was going to be.
Just so I can properly understand, how much of the -0.5 is "don't like
the idea" vs "rather make changes to well-known behaviour"?
David
David Rowley writes:
> There are still no votes against it, so unless some come in, I plan to
> start looking at the patches proposed to turn buffers on with analyze
> with my committer hat on.
I'm kind of -0.5, but I'd not bothered to vote because it was
pretty clear what the result was going to
On Tue, 26 Nov 2024 at 09:44, Robert Haas wrote:
>
> On Wed, Nov 20, 2024 at 4:23 PM David Rowley wrote:
> > I think this might be a good time for anyone out there who is against
> > turning on BUFFERS when ANALYZE is on to speak up.
> >
> > Votes for changing this so far seem to be: Me, Michael
On Wed, Nov 20, 2024 at 4:23 PM David Rowley wrote:
> On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge
> wrote:
> > OK, I'm fine with this. v4 patch attached with one plan showing read,
> > written, and dirtied buffers.
>
> I think this might be a good time for anyone out there who is against
>
On Wed, 2024-11-20 at 22:54 +0100, Vik Fearing wrote:
> On 20/11/2024 22:22, David Rowley wrote:
> > On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge
> > wrote:
> > > OK, I'm fine with this. v4 patch attached with one plan showing read,
> > > written, and dirtied buffers.
> > I think this might b
On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge wrote:
> OK, I'm fine with this. v4 patch attached with one plan showing read,
> written, and dirtied buffers.
I think this might be a good time for anyone out there who is against
turning on BUFFERS when ANALYZE is on to speak up.
Votes for chang
On 20/11/2024 22:22, David Rowley wrote:
On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge wrote:
OK, I'm fine with this. v4 patch attached with one plan showing read, written,
and dirtied buffers.
I think this might be a good time for anyone out there who is against
turning on BUFFERS when A
On Thu, Nov 21, 2024 at 10:22:54AM +1300, David Rowley wrote:
> On Thu, 21 Nov 2024 at 08:30, Guillaume Lelarge
> wrote:
> > OK, I'm fine with this. v4 patch attached with one plan showing read,
> > written, and dirtied buffers.
>
> I think this might be a good time for anyone out there who is
Le mer. 20 nov. 2024 à 16:51, Greg Sabino Mullane a
écrit :
> On Wed, Nov 20, 2024 at 1:26 AM Guillaume Lelarge
> wrote:
>
>> OK, but I'm not sure which example I should pick to add dirtied and
>> written shared buffers. It looks kinda artificial. Should I choose one
>> randomly?
>>
>
> It will
On Wed, Nov 20, 2024 at 1:26 AM Guillaume Lelarge
wrote:
> OK, but I'm not sure which example I should pick to add dirtied and
> written shared buffers. It looks kinda artificial. Should I choose one
> randomly?
>
It will be artificial, but I think that's ok: anyone running it on their
own will
Le mer. 20 nov. 2024 à 01:13, Greg Sabino Mullane a
écrit :
> I'm with Robert on this one. I'm a grudging +1 to buffers defaulting on,
> and a strong -1 to all the other proposals. Guillaume, the patch looks
> pretty good.
>
Thanks :)
> I would like to see some of the example output have more
I'm with Robert on this one. I'm a grudging +1 to buffers defaulting on,
and a strong -1 to all the other proposals. Guillaume, the patch looks
pretty good. I would like to see some of the example output have more than
just "shared hit" and "read" though: let's throw some "dirtied" and
"written" in
>
> Maybe the wording could just be based on the wording for the SUMMARY
> option, i.e. "Summary information is included by default when ANALYZE
> is used but otherwise is not included by default".
>
Yes, I like that. Avoids the whole TRUE/FALSE altogether.
Thanks,
Greg
On Wed, 20 Nov 2024 at 13:13, Greg Sabino Mullane wrote:
>> It defaults to TRUE when ANALYZE is
>> also enabled. Otherwise, it defaults to FALSE.
>
> Is that second sentence really needed? Because "BUFFERS ON" will never be
> needed anymore (save as a no-op to allow the same explain queries to r
Hello,
Le mar. 12 nov. 2024 à 22:21, Robert Haas a écrit :
> On Tue, Nov 12, 2024 at 4:02 PM Guillaume Lelarge
> wrote:
> > Sure looks easy enough to do (though it still lacks doc and tests
> changes). See patch attached.
>
> Yep, that's very small. I'm a bit wondering if it's too small, though
On Tue, Nov 12, 2024 at 4:02 PM Guillaume Lelarge
wrote:
> Sure looks easy enough to do (though it still lacks doc and tests changes).
> See patch attached.
Yep, that's very small. I'm a bit wondering if it's too small, though.
standard_ExplainOneQuery() seems to do some stuff with es->buffers
e
Le mar. 12 nov. 2024 à 16:35, Guillaume Lelarge a
écrit :
> Le mar. 12 nov. 2024 à 16:21, Robert Haas a
> écrit :
>
>> On Mon, Nov 11, 2024 at 3:59 PM Guillaume Lelarge
>> wrote:
>> > Agreed. Having an "EXPLAIN (ALL)" would be a great addition. I could
>> tell a customer to do an "EXPLAIN (ALL)
Le mar. 12 nov. 2024 à 16:21, Robert Haas a écrit :
> On Mon, Nov 11, 2024 at 3:59 PM Guillaume Lelarge
> wrote:
> > Agreed. Having an "EXPLAIN (ALL)" would be a great addition. I could
> tell a customer to do an "EXPLAIN (ALL)", rather than first asking the
> PostgreSQL release installed on the
On Mon, Nov 11, 2024 at 3:59 PM Guillaume Lelarge
wrote:
> Agreed. Having an "EXPLAIN (ALL)" would be a great addition. I could tell a
> customer to do an "EXPLAIN (ALL)", rather than first asking the PostgreSQL
> release installed on the server and after that, giving the correct options
> for
Hi,
Le mer. 6 nov. 2024 à 17:57, Michael Christofides a
écrit :
> [...]
> I agree. In the past 6 versions, 5 new parameters have been added.
> SETTINGS in v12, WAL in v13, GENERIC_PLAN in v16, SERIALIZE in
> v17, and MEMORY in v17. It feels like we should have some easier way
> to get everything
On 05.11.24 19:19, Robert Haas wrote:
1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
Let's rename it to EXPLAIN EXECUTE?
The trouble is that EXPLAIN EXECUTE already means something.
robert.haas=# explain execute foo;
ERROR: prepared statement "foo" does not exist
>
> I'm not against analyze = on turning buffers on by default. However, I
> think it would be quite painful to fix the tests if it were on without
> analyze.
>
This would be amazing. I'm finding BUFFERS are especially helpful for
giving developers a clearer idea of why their queries are slow (esp
On Wed, 6 Nov 2024 at 12:33, David G. Johnston
wrote:
> The main premise here is that explain should include buffers by default, and
> to do so we are willing to inconvenience testers who do not want buffer data
> in their test plans to have to modify their tests to explicitly exclude
> buffers
On Wed, 6 Nov 2024 at 13:14, Kirk Wolak wrote:
> But, personally, as a relatively new person to PG, I was surprised that
> VERBOSE did not include the buffers.
> Could we somehow turn this on? (GUC: VERBOSE_INCLUDES_BUFFERS = yes/no)?
Please read
https://postgr.es/m/CA+TgmoYH_p-y=45saj58cu6jsm
On Tue, Nov 5, 2024 at 1:19 PM Nikolay Samokhvalov
wrote:
>
>> > 2) VERBOSE doesn't include BUFFERS, and doesn't include SETTINGS; it
>> might
>> > be also confusing sometimes. Let's include them so VERBOSE would be
>> really
>> > verbose?
>>
>> This is not likely to fly for compatibility reasons
On Tue, Nov 5, 2024 at 3:55 PM Nikolay Samokhvalov
wrote:
>
> 4. Making BUFFERS default behavior for EXPLAIN ANALYZE was raised several
> times, for example
> https://www.postgresql.org/message-id/flat/CANNMO++=LrJ4upoeydZhbmpd_ZgZjrTLueKSrivn6xmb=yf...@mail.gmail.com
> (2021) – and my understand
On Tue, Nov 5, 2024 at 2:54 PM Nikolay Samokhvalov
wrote:
> 6. FInally, the fresh SERIALIZE option was discussed in
> https://www.postgresql.org/message-id/flat/ca0adb0e-fa4e-c37e-1cd7-91170b18cae1%40gmx.de
> (2023-2024, 17), and unfortunately again.
>
(didn't finish the phrase here and hit Send
On Tue, Nov 5, 2024 at 10:30 AM Tom Lane wrote:
> we're not working in a green field here, and all these
> decisions have history.
>
I hear you and understand.
Ready to do legwork here.
1. VERBOSE first appeared in 1997 in 6.3 in 3a02ccfa, with different
meaning:
> This command [EXPLAIN] ou
On Tue, Nov 5, 2024 at 1:24 PM Nikolay Samokhvalov
wrote:
> Item 3 is already solved, as it turned out.
ANALYZE and VERBOSE are treated specially because those options
existed prior to the parenthesized syntax. Scaling that treatment to a
large number of options will not work out.
> Let's focus
Nikolay Samokhvalov writes:
> Let's focus on item 2. Is it really impossible to make VERBOSE really
> verbose?
It's obviously not "impossible" -- the code changes would likely be
trivial. The question is whether it's a good idea. These semantics
were (I presume) deliberately chosen when the opt
On Tue, Nov 5, 2024 at 1:02 PM Nikolay Samokhvalov
wrote:
> hi, I have a proposal, resulted from numerous communications with various
> folks, both very experienced and new Postgres users:
>
> 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
> Let's rename it to EXPLAIN
On Tue, Nov 5, 2024 at 10:19 AM Robert Haas wrote:
> On Tue, Nov 5, 2024 at 1:02 PM Nikolay Samokhvalov
> wrote:
> > hi, I have a proposal, resulted from numerous communications with
> various folks, both very experienced and new Postgres users:
> >
> > 1) EXPLAIN ANALYZE Is sometimes very confu
On Tue, Nov 5, 2024 at 10:16 AM Tom Lane wrote:
> Nikolay Samokhvalov writes:
> > 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is
> ANALYZE).
> > Let's rename it to EXPLAIN EXECUTE?
>
> This has got far too many years of history to be renamed now.
>
This is a really, really str
Nikolay Samokhvalov writes:
> 1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
> Let's rename it to EXPLAIN EXECUTE?
This has got far too many years of history to be renamed now.
> 2) VERBOSE doesn't include BUFFERS, and doesn't include SETTINGS; it might
> be also conf
hi, I have a proposal, resulted from numerous communications with various
folks, both very experienced and new Postgres users:
1) EXPLAIN ANALYZE Is sometimes very confusing (because there is ANALYZE).
Let's rename it to EXPLAIN EXECUTE?
2) VERBOSE doesn't include BUFFERS, and doesn't include SET
56 matches
Mail list logo
