Re: Open issues for HOT patch
От | Bruce Momjian |
---|---|
Тема | Re: Open issues for HOT patch |
Дата | |
Msg-id | 200709181449.l8IEnCp02401@momjian.us обсуждение исходный текст |
Ответ на | Re: Open issues for HOT patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> But then what happens when you want to update a second tuple on the same > >> page? None of our existing plan types release and reacquire pin if they > >> don't have to, and I really doubt that we want to give up that > >> optimization. > > > You will prune when you lock the page and at that point unless you got > > enough room for both tuples I doubt trying just before the second tuple > > is going to help. > > No, you're missing the point completely. If the free space on the page > is, say, 1.5x the average tuple size, the code *won't* prune, and then > it will be stuck when it goes to do the second tuple update, because > there is no chance to reconsider the prune/no-prune decision after some > space is eaten by the first update. My point is that if you only do this for INSERT/UPDATE, you can prune when you have less than enough room for 3-4 tuples, and if you add the xmin of the earliest prune xact you can prune even more aggressively. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: