Re: Automatic free space map filling

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas DCP SD
Тема Re: Automatic free space map filling
Дата
Msg-id E1539E0ED7043848906A8FF995BDA579D98B19@m0143.s-mxs.net
обсуждение исходный текст
Ответ на Automatic free space map filling  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Automatic free space map filling  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: qsort again (was Re: [PERFORM] Strange Create Index behaviour)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [SQL] Interval subtracting