From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hannu Krosing <hannu(at)skype(dot)net> |
Cc: | Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Automatic free space map filling |
Date: | 2006-03-02 15:05:28 |
Message-ID: | 2657.1141311928@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hannu Krosing <hannu(at)skype(dot)net> writes:
> hel kenal peval, N, 2006-03-02 kell 09:53, kirjutas Zeugswetter
> Andreas DCP SD:
>> 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.
> I don't even think you need the header, just truncate the slot to be
> 0-size
I think you must keep the header because the tuple might be part of an
update chain (cf vacuuming bugs we repaired just a few months ago).
t_ctid is potentially interesting data even in a certainly-dead tuple.
Andreas' idea is possibly doable but I am not sure that I see the point.
It does not reduce the need for vacuum nor the I/O load imposed by
vacuum. What it does do is bias the system in the direction of
allocating an unreasonably large number of tuple line pointers on a page
(ie, more than are useful when the page is fully packed with normal
tuples). Since we never reclaim such pointers, over time all the pages
in a table would tend to develop line-pointer-bloat. I don't know what
the net overhead would be, but it'd definitely impose some aggregate
inefficiency.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | George Weaver | 2006-03-02 15:12:26 | pg_config --pgxs |
Previous Message | Andrew - Supernews | 2006-03-02 14:58:37 | Re: ACCESS EXCLUSIVE LOCK |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-03-02 16:13:09 | Re: [SQL] Interval subtracting |
Previous Message | Andrew - Supernews | 2006-03-02 14:58:37 | Re: ACCESS EXCLUSIVE LOCK |