On 07/12/2018 12:38 PM, Claudio Freire wrote:
On Thu, Jul 12, 2018 at 10:44 AM Andrew Dunstan
<andrew.duns...@2ndquadrant.com> wrote:
On 04/06/2018 08:00 PM, Claudio Freire wrote:
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire <klaussfre...@gmail.com> wrote:
On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
On 06/04/18 01:59, Claudio Freire wrote:
The iteration interface, however, seems quite specific for the use
case of vacuumlazy, so it's not really a good abstraction.
Can you elaborate? It does return the items one block at a time. Is that
what you mean by being specific for vacuumlazy? I guess that's a bit
special, but if you imagine some other users for this abstraction, it's
probably not that unusual. For example, if we started using it in bitmap
heap scans, a bitmap heap scan would also want to get the TIDs one block
number at a time.
But you're also tying the caller to the format of the buffer holding
those TIDs, for instance. Why would you, when you can have an
interface that just iterates TIDs and let the caller store them
if/however they want?
I do believe a pure iterator interface is a better interface.
Between the b-tree or not discussion and the refactoring to separate
the code, I don't think we'll get this in the next 24hs.
So I guess we'll have ample time to poner on both issues during the
next commit fest.
There doesn't seem to have been much pondering done since then, at least
publicly. Can we make some progress on this? It's been around for a long
time now.
Yeah, life has kept me busy and I haven't had much time to make
progress here, but I was planning on doing the refactoring as we were
discussing soon. Can't give a time frame for that, but "soonish".
I fully understand. I think this needs to go back to "Waiting on Author".
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
