From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Trouble with hashagg spill I/O pattern and costing |
Date: | 2020-05-26 18:40:07 |
Message-ID: | e913544f6c236d37e8b0597cabd086570b5806f2.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2020-05-26 18:50:50 | Re: PG_CRON logging |
Previous Message | Rajin Raj | 2020-05-26 18:38:53 | PG_CRON logging |