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 по дате отправления: