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 по дате отправления: