Re: Automatic free space map filling

From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hannu Krosing" <hannu(at)skype(dot)net>
Cc: "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 19:07:53
Message-ID: E1539E0ED7043848906A8FF995BDA579D98B19@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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.

yes, I'd still want to keep the full header.

> 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.

Ok, for vacuum the slot would look like any other dead row and thus be
target for removal.

Why do we not truncate the line pointer array ?
Is it, that vacuum (not the "full" version) does not move
rows to other pages or slots ? Of course vacuum full could do it,
but I see your point.
Maybe we could impose an upper limit on the number of slots to allow,
after which the optimization is turned off.
But this starts to sound not so good :-(

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-03-02 19:10:53 Re: [SQL] Interval subtracting
Previous Message Jonah H. Harris 2006-03-02 18:50:24 Re: qsort again (was Re: [PERFORM] Strange Create Index behaviour)