Re: 8.3.0 Core with concurrent vacuum fulls
| От | Tom Lane |
|---|---|
| Тема | Re: 8.3.0 Core with concurrent vacuum fulls |
| Дата | |
| Msg-id | 18945.1204826425@sss.pgh.pa.us обсуждение |
| Ответ на | Re: 8.3.0 Core with concurrent vacuum fulls ("Pavan Deolasee" <pavan.deolasee@gmail.com>) |
| Ответы |
Re: 8.3.0 Core with concurrent vacuum fulls
Re: 8.3.0 Core with concurrent vacuum fulls |
| Список | pgsql-hackers |
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On Wed, Mar 5, 2008 at 9:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ 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.
> We can actually combine this and the page copying ideas. Instead of copying
> the entire page, we can just copy the line pointers array and work on the copy.
I think that just makes things more complex and fragile. I like
Heikki's idea, in part because it makes the normal path and the WAL
recovery path guaranteed to work alike. I'll attach my work-in-progress
patch for this --- it doesn't do anything about the invalidation
semantics problem but it does fix the critical-section-too-big problem.
regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: