From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Vacuum: allow usage of more than 1GB of work mem |
Date: | 2018-04-07 00:00:20 |
Message-ID: | CAGTBQpY_MOmrnysfAdbOy2ghAtohFuf5vOTJQ9mrTtTkc+VgeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-07 00:03:24 | Re: [HACKERS] Runtime Partition Pruning |
Previous Message | Stephen Frost | 2018-04-06 23:52:55 | Re: Online enabling of checksums |