On Wed, Jun 28, 2017 at 7:43 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > > On Wed, Jun 28, 2017 at 12:00 AM, Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: >> >> On Tue, Jun 27, 2017 at 4:19 PM, Amit Kapila <amit.kapil...@gmail.com> >> wrote: >>> >>> On Thu, Jun 22, 2017 at 5:46 PM, Alexander Korotkov >>> <a.korot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
