On Thu, Sep 15, 2016 at 2:40 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 14 September 2016 at 11:19, Pavan Deolasee <pavan.deola...@gmail.com> > wrote: > >>> In >>> theory we could even start with the list of TIDs and switch to the >>> bitmap if the TID list becomes larger than the bitmap would have been, >>> but I don't know if it's worth the effort. >>> >> >> Yes, that works too. Or may be even better because we already know the >> bitmap size requirements, definitely for the tuples collected so far. We >> might need to maintain some more stats to further optimise the >> representation, but that seems like unnecessary detailing at this point. > > That sounds best to me... build the simple representation, but as we > do maintain stats to show to what extent that set of tuples is > compressible. > > When we hit the limit on memory we can then selectively compress > chunks to stay within memory, starting with the most compressible > chunks. > > I think we should use the chunking approach Robert suggests, though > mainly because that allows us to consider how parallel VACUUM should > work - writing the chunks to shmem. That would also allow us to apply > a single global limit for vacuum memory rather than an allocation per > VACUUM. > We can then scan multiple indexes at once in parallel, all accessing > the shmem data structure. >
Yeah, the chunking approach Robert suggested seems like a good idea but considering implementing parallel vacuum, it would be more complicated IMO. I think It's better the multiple process simply allocate memory space for its process than that the single process allocate huge memory space using complicated way. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
