Re: Automatic free space map filling - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: Automatic free space map filling
Date
Msg-id E1539E0ED7043848906A8FF995BDA579D989B5@m0143.s-mxs.net
Whole thread Raw
In response to Automatic free space map filling  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Automatic free space map filling  (Hannu Krosing <hannu@skype.net>)
Re: Automatic free space map filling  (ITAGAKI Takahiro <itagaki.takahiro@lab.ntt.co.jp>)
List pgsql-hackers
> I thought we had sufficiently destroyed that "reuse a tuple"
> meme yesterday.  You can't do that: there are too many
> aspects of the system design that are predicated on the
> assumption that dead tuples do not come back to life.  You
> have to do the full vacuuming bit (index entry removal,
> super-exclusive page locking, etc) before you can remove a dead tuple.

One more idea I would like to throw in.
Ok, we cannot reuse a dead tuple. Maybe we can reuse the space of a dead
tuple by reducing the tuple to it's header info.
(If you still wanted to be able to locate index entries fast,
you would need to keep indexed columns, but I think we agreed that there
is
no real use)

I think that would be achievable at reasonable cost (since you can avoid
one page IO)
on the page of the currently active tuple (the first page that is
considered).

On this page:
if freespace available --> use it
elsif freespace available after reducing all dead rows  --> use the freespace with a new slot
else ....

Of course this only works when we still have free slots,
but I think that might not really be an issue.

Andreas


pgsql-hackers by date:

Previous
From:
Date:
Subject: Re: Initdb on Windows 2003
Next
From: Hannu Krosing
Date:
Subject: Re: Automatic free space map filling