Re: Trouble with hashagg spill I/O pattern and costing
Jeff Davis <pgsql@j-davis.com>
From: Jeff Davis <pgsql@j-davis.com>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Thomas Munro <thomas.munro@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-05-26T18:40:07Z
Lists: pgsql-hackers
On Tue, 2020-05-26 at 16:15 +0200, Tomas Vondra wrote: > I'm not familiar with logtape internals but IIRC the blocks are > linked > by each block having a pointer to the prev/next block, which means we > can't prefetch more than one block ahead I think. But maybe I'm > wrong, > or maybe fetching even just one block ahead would help ... We'd have to get creative. Keeping a directory in the LogicalTape structure might work, but I'm worried the memory requirements would be too high. One idea is to add a "prefetch block" to the TapeBlockTrailer (perhaps only in the forward direction?). We could modify the prealloc list so that we always know the next K blocks that will be allocated to the tape. All for v14, of course, but I'd be happy to hack together a prototype to collect data. Do you have any other thoughts on the current prealloc patch for v13, or is it about ready for commit? Regards, Jeff Davis
Commits
-
Use CP_SMALL_TLIST for hash aggregate
- 4cad2534da6d 13.0 landed
-
Avoid fragmentation of logical tapes when writing concurrently.
- 896ddf9b3cd7 13.0 landed