Re: Trouble with hashagg spill I/O pattern and costing
От | Jeff Davis |
---|---|
Тема | Re: Trouble with hashagg spill I/O pattern and costing |
Дата | |
Msg-id | e913544f6c236d37e8b0597cabd086570b5806f2.camel@j-davis.com обсуждение исходный текст |
Ответ на | Re: Trouble with hashagg spill I/O pattern and costing (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: Trouble with hashagg spill I/O pattern and costing
|
Список | 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
В списке pgsql-hackers по дате отправления: