From: | Jim Nasby <jnasby(at)pervasive(dot)com> |
---|---|
To: | Nicolai Petri <nicolai(at)catpipe(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PFC <lists(at)peufeu(dot)com> |
Subject: | Re: Faster Updates |
Date: | 2006-06-05 13:10:07 |
Message-ID: | 7E4832B3-803A-4BFB-9BD7-C90BC1CB1613@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)peufeu(dot)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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-06-05 13:14:08 | Re: non-transactional pg_class |
Previous Message | Simon Riggs | 2006-06-05 09:42:36 | Re: XLOG_BLCKSZ vs. wal_buffers table |