Re: Faster Updates

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Faster Updates
Дата
Msg-id 7E4832B3-803A-4BFB-9BD7-C90BC1CB1613@pervasive.com
обсуждение исходный текст
Ответ на Re: Faster Updates  (Nicolai Petri <nicolai@catpipe.net>)
Список pgsql-hackers
On Jun 3, 2006, at 2:05 PM, Nicolai Petri wrote:

> On Saturday 03 June 2006 17:27, Tom Lane wrote:
>> PFC <lists@peufeu.com> writes:
>>>    [snip - complicated update logic proprosal]
>>>     What do you think ?
>>
>> Sounds enormously complicated and of very doubtful net win --- you're
>>
>> [snip - ... bad idea reasoning] :)
>
> What if every backend while processing a transaction collected a  
> list of
> touched records - probably with a max number of entries (GUC)  
> collected per
> transaction. Then when transaction completes the list of touples  
> are sent to
> pg_autovacuum or possible a new process that selectively only went  
> for those
> tupples. Of course it should have some kind of logic connected so  
> we don't
> visit the tupples for vacuum unless we are quite sure no running  
> transactions
> would be blocking adding the blocks to the FSM. We might be able to  
> actually
> queue up the blocks until a later time (GUC queue-max-time +
> queue-size-limit) if we cannot determine that it would be safe to  
> FSM the
> blocks at current time.
>
> I guess this has probably been suggested before and there is  
> probably a reason

Yup. Search the archives for 'dead space map'.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: 'CVS-Unknown' buildfarm failures?
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: 'CVS-Unknown' buildfarm failures?