On Wed, Jun 28, 2017 at 7:43 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
>
> On Wed, Jun 28, 2017 at 12:00 AM, Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
>>
>> On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>>>
>>> On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov
>>> <a.korotkov@postgrespro.ru> wrote:
>>>
>>> Probably, some other algorithm for vacuum. I am not sure current
>>> vacuum with its parameters can be used so easily. One thing that
>>> might need some thoughts is that is it sufficient to say that keep
>>> autovacuum as off and call some different API for places where the
>>> vacuum can be invoked manually like Vacuum command to the developer
>>> implementing some different strategy for vacuum or we need something
>>> more as well.
>>
>>
>> What kind of other vacuum algorithm do you expect? It would be rather
>> easier to understand if we would have examples.
>>
>> For me, changing of vacuum algorithm is not needed for just heap page
>> format change. Existing vacuum algorithm could just call page format API
>> functions for manipulating individual pages.
>>
>> Changing of vacuum algorithm might be needed for more invasive changes
>> than just heap page format. However, we should first understand what these
>> changes could be and how are they consistent with rest of API design.
>
>
> Yes, I agree that we need some changes in the vacuum to handle the pluggable
> storage.
> Currently I didn't fully checked the changes that are needed in vacuum, but
> I feel the low level changes of the function are enough, and also there
> should be
> some option from storage handler to decide whether it needs a vacuum or not?
> Based on this flag, the vacuum may be skipped on those tables. So these
> handlers
> no need to register those API's.
>
Something in that direction sounds reasonable to me. I am also not
very clear what kind of pluggability will be required for vacuum. I
think for now we can park this problem and try to tackle tuple format
and page format related stuff.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com