On Tue, Mar 12, 2019 at 4:54 PM Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > > On Mon, Mar 11, 2019 at 1:37 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: >> >> >> >> I might be missing something but why do we need to recheck whether >> each pages is all-frozen after insertion? I wonder if we can set >> all-frozen without checking all tuples again in this case. > > > It's possible that the user may have inserted unfrozen rows (via regular > INSERT or COPY without FREEZE option) before inserting frozen rows.
I think that since COPY FREEZE can be executed only when the table is created or truncated within the transaction other users cannot insert any rows during COPY FREEZE. > So we can't set the all-visible/all-frozen flag unconditionally. I also find > it safer to do an explicit check to ensure we never accidentally mark a page > as all-frozen. Since the check is performed immediately after the page > becomes full and only once per page, there shouldn't be any additional IO > cost and the check should be quite fast. I'd suggest to measure performance overhead. I can imagine one use case of COPY FREEZE is the loading a very large table. Since in addition to set visibility map bits this patch could scan a very large table I'm concerned that how much performance is degraded by this patch. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
