Re: WAL usage calculation patch
Julien Rouhaud <rjuju123@gmail.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
Attachments
- v6-0001-Track-WAL-usage.patch (text/plain)
On Thu, Mar 19, 2020 at 09:03:02PM +0900, Fujii Masao wrote: > > On 2020/03/19 2:19, Julien Rouhaud wrote: > > > > I'm attaching a v5 with fp records only for temp tables, so there's no risk of > > instability. As I previously said I'm fine with your two patches, so unless > > you have objections on the fpi test for temp tables or the documentation > > changes, I believe those should be ready for committer. > > You added the columns into pg_stat_database, but seem to forget to > update the document for pg_stat_database. Ah right, I totally missed that when I tried to clean up the original POC. > Is it really reasonable to add the columns for vacuum's WAL usage into > pg_stat_database? I'm not sure how much the information about > the amount of WAL generated by vacuum per database is useful. The amount per database isn't really useful, but I didn't had a better idea on how to expose (auto)vacuum WAL usage until this: > Isn't it better to make VACUUM VERBOSE and autovacuum log include > that information, instead, to see how much each vacuum activity > generates the WAL? Sorry if this discussion has already been done > upthread. That's a way better idea! I'm attaching the full patchset with the 3rd patch to use this approach instead. There's a bit a duplicate code for computing the WalUsage, as I didn't find a better way to avoid that without exposing WalUsageAccumDiff(). Autovacuum log sample: 2020-03-19 15:49:05.708 CET [5843] LOG: automatic vacuum of table "rjuju.public.t1": index scans: 0 pages: 0 removed, 2213 remain, 0 skipped due to pins, 0 skipped frozen tuples: 250000 removed, 250000 remain, 0 are dead but not yet removable, oldest xmin: 502 buffer usage: 4448 hits, 4 misses, 4 dirtied avg read rate: 0.160 MB/s, avg write rate: 0.160 MB/s system usage: CPU: user: 0.13 s, system: 0.00 s, elapsed: 0.19 s WAL usage: 6643 records, 4 full page records, 1402679 bytes VACUUM log sample: # vacuum VERBOSE t1; INFO: vacuuming "public.t1" INFO: "t1": removed 50000 row versions in 443 pages INFO: "t1": found 50000 removable, 0 nonremovable row versions in 443 out of 443 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 512 There were 50000 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. 1332 WAL records, 4 WAL full page records, 306901 WAL bytes CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s. INFO: "t1": truncated 443 to 0 pages DETAIL: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s INFO: vacuuming "pg_toast.pg_toast_16385" INFO: index "pg_toast_16385_index" now contains 0 row versions in 1 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. INFO: "pg_toast_16385": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 513 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. 0 WAL records, 0 WAL full page records, 0 WAL bytes CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. VACUUM Note that the 3rd patch is an addition on top of Kirill's original patch, as this is information that would have been greatly helpful to investigate in some performance issues I had to investigate recently. I'd be happy to have it land into v13, but if that's controversial or too late I'm happy to postpone it to v14 if the infrastructure added in Kirill's patches can make it to v13.