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  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: 8.3.0 Core with concurrent vacuum fulls  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Psql command-line completion bug
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Intended behaviour of SET search_path with SQL functions?