"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think we really are at too much risk of PANIC the way it's being done >> now. Has anyone got a better idea?
> We could do the pruning in two phases: first figure out what to do > without modifyng anything, outside critical-section, and then actually > do it, inside critical section. > Looking at heap_page_prune, we already collect information of what we > did in the redirected/nowdead/nowunused arrays for WAL logging purposes. That's a thought, but ... > We could use that, but we would also have to teach heap_prune_chain to > not step into tuples that we've already decided to remove. ... seems like this would require searching the aforementioned arrays for each tuple examined, which could turn into an O(N^2) problem. If there are many removable tuples it could easily end up slower than copying. [ thinks some more... ] I guess we could use a flag array dimensioned MaxHeapTuplesPerPage to mark already-processed tuples, so that you wouldn't need to search the existing arrays but just index into the flag array with the tuple's offsetnumber. I wonder if the logic could be restructured to avoid this by taking advantage of it being a two-pass process, instead of fighting it? But that'd probably be a bigger change than we'd want to risk back-patching. Since I'm the one complaining about the PANIC risk, I guess I should do the legwork here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-hackers