Re: logtape.c stats don't account for unused "prefetched" block numbers

Jeff Davis <pgsql@j-davis.com>

View thread View on postgr.es

From: Jeff Davis <pgsql@j-davis.com>

To: Peter Geoghegan <pg@bowt.ie>

Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2020-09-15T06:44:47Z

Lists: pgsql-hackers

Attachments

logtape-nblockswritten.patch (text/x-patch) patch

On Mon, 2020-09-14 at 20:48 -0700, Peter Geoghegan wrote:
> On Mon, Sep 14, 2020 at 8:07 PM Jeff Davis <pgsql@j-davis.com> wrote:
> > Sure. Will backporting either patch into REL_13_STABLE now
> > interfere
> > with RC1 release in any way?
> 
> The RMT will discuss this.
> 
> It would help if there was a patch ready to go.

Attached. HashAgg seems to accurately reflect the filesize, as does
Sort.

Regards,
	Jeff Davis

Commits

Change LogicalTapeSetBlocks() to use nBlocksWritten.
- 6e146a663536 13.0 landed
- c8aeaf3ab31e 14.0 landed
HashAgg: release write buffers sooner by rewinding tape.
- 42a46f5a76ec 13.0 landed
- 3bd35d4f516a 14.0 landed
logtape.c: do not preallocate for tapes when sorting
- 93106d71a18a 13.0 landed
- 075896496394 14.0 landed
Fix bogus MaxAllocSize check in logtape.c.
- 4a4f3bf983b4 13.0 landed
- 0852006a946a 14.0 landed
Avoid fragmentation of logical tapes when writing concurrently.
- 896ddf9b3cd7 13.0 cited
Logical Tape Set: use min heap for freelist.
- c02fdc922301 13.0 cited
Don't create "holes" in BufFiles, in the new logtape code.
- 7ac4a389a7db 10.0 cited