Re: Freeze avoidance of very large table.
От | Masahiko Sawada |
---|---|
Тема | Re: Freeze avoidance of very large table. |
Дата | |
Msg-id | CAD21AoBKF0C353DpdfGSJ_85kAWTTfvUt3hs6LLYdGomtVmY-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Freeze avoidance of very large table. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Freeze avoidance of very large table.
|
Список | pgsql-hackers |
On Fri, Mar 11, 2016 at 6:16 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 10, 2016 at 1:41 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas <robertmhaas@gmail.com> wrote: >>> This 001 patch looks so little like what I was expecting that I >>> decided to start over from scratch. The new version I wrote is >>> attached here. I don't understand why your version tinkers with the >>> logic for setting the all-frozen bit; I thought that what I already >>> committed dealt with that already, and in any case, your version >>> doesn't even compile against latest sources. Your version also leaves >>> the scan_all terminology intact even though it's not accurate any >>> more, and I am not very convinced that the updates to the >>> page-skipping logic are actually correct. Please have a look over >>> this version and see what you think. >> >> Thank you for your advise. >> Sorry, optimising logic of previous patch was old by mistake. >> Attached latest patch incorporated your suggestions with a little revising. > > Thanks. I adopted some of your suggested, rejected others, fixed a > few minor things that I missed previously, and committed this. If you > think any of the changes that I rejected still have merit, please > resubmit those changes as separate patches. > Thank you for your effort to this feature and committing it. I guess that I couldn't do good work to this feature at final stage, but I really appreciate all your advice and suggestion. > I think what I really want is some logic so that if we have a 1-page > visibility map in the old cluster and the second half of that page is > all zeroes, we only create a 1-page visibility map in the new cluster > rather than a 2-page visibility map. > > Or more generally, if the old VM is N pages, but the last half of the > last page is empty, then let the output VM be 2*N-1 pages instead of > 2*N pages. > I got your point. Attached latest patch can skip to write the last part of last old page if it's empty. Please review it. Regards, -- Masahiko Sawada
Вложения
В списке pgsql-hackers по дате отправления: