Re: WAL usage calculation patch
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Change the display of WAL usage statistics in Explain.
- 69bfaf2e1de4 13.0 landed
-
Cosmetic fixups for WAL usage work.
- ef08ca113fe3 13.0 landed
-
Allow parallel create index to accumulate buffer usage stats.
- 5c71362174eb 13.0 landed
- f179e9f01b65 11.8 landed
- 13823ad3b012 12.3 landed
-
Allow autovacuum to log WAL usage statistics.
- b7ce6de93b59 13.0 landed
-
Add the option to report WAL usage in EXPLAIN and auto_explain.
- 33e05f89c53e 13.0 landed
-
Allow pg_stat_statements to track WAL usage statistics.
- 6b466bf5f2be 13.0 landed
-
Add infrastructure to track WAL usage.
- df3b181499b4 13.0 landed
-
Include information on buffer usage during planning phase, in EXPLAIN output, take two.
- ce77abe63cfc 13.0 cited
-
Include information on buffer usage during planning phase, in EXPLAIN output.
- ed7a5095716e 13.0 cited
-
Allow parallel vacuum to accumulate buffer usage.
- 3a5e22138a8d 13.0 landed
-
Allow pg_stat_statements to track planning statistics.
- 17e03282241c 13.0 cited
On 2020-04-07 04:12, Amit Kapila wrote:
> On Mon, Apr 6, 2020 at 10:01 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>>
>> On Mon, Apr 06, 2020 at 05:01:30PM +0200, Peter Eisentraut wrote:
>>> I noticed in some of the screenshots that were tweeted that for example in
>>>
>>> WAL: records=1 bytes=56
>>>
>>> there are two spaces between pieces of data. This doesn't match the rest of
>>> the EXPLAIN output. Can that be adjusted?
>>
>> We talked about that here:
>> https://www.postgresql.org/message-id/20200402054120.GC14618%40telsasoft.com
>>
>
> Yeah. Just to brief here, the main reason was that one of the fields
> (full page writes) already had a single space and then we had prior
> cases as mentioned in Justin's email [1] where we use two spaces which
> lead us to decide using two spaces in this case.
We also have existing cases for the other way:
actual time=0.050..0.052
Buffers: shared hit=3 dirtied=1
The cases mentioned by Justin are not formatted in a key=value format,
so it's not quite the same, but it also raises the question why they are
not.
Let's figure out a way to consolidate this without making up a third format.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services