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 E1539E0ED7043848906A8FF995BDA579D98B19@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
List 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


pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: qsort again (was Re: [PERFORM] Strange Create Index behaviour)
Next
From: Tom Lane
Date:
Subject: Re: [SQL] Interval subtracting