Re: cutting down the TODO list thread

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: cutting down the TODO list thread
Дата
Msg-id CAFBsxsE5TybnCqmzar6o+XZerLkhaOVS=afdBaFx3dQmVrfzRA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: cutting down the TODO list thread  (John Naylor <john.naylor@enterprisedb.com>)
Ответы Re: cutting down the TODO list thread  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
It's been a while, but here are a few more suggested
removals/edits/additions to the TODO list. Any objections or new
information, let me know:

- Auto-fill the free space map by scanning the buffer cache or by
checking pages written by the background writer
http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php
https://www.postgresql.org/message-id/200603011716.16984.peter_e@gmx.net

Both these threads are from 2006, so have nothing to do with the current FSM.

- Allow concurrent inserts to use recently created pages rather than
creating new ones
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php

Skimming the first few messages, I believe this has been covered by
commit 719c84c1b? (Extend relations multiple blocks at a time to
improve scalability.)

- Allow VACUUM FULL and CLUSTER to update the visibility map

This topic has a current CF entry which seems to have stalled, so that
newer thread would be better to list here than the one from 2013.

- Bias FSM towards returning free space near the beginning of the heap
file, in hopes that empty pages at the end can be truncated by VACUUM
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php
https://www.postgresql.org/message-id/20150424190403.GP4369@alvh.no-ip.org

I'm not sure what to think of this, but independently of that, the
second thread is actually talking about bringing back something like
the pre-9.0 vacuum full, so maybe it should be its own entry?

- Consider a more compact data representation for dead tuple locations
within VACUUM
http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php

Great, but let's link to this more recent thread instead:
https://www.postgresql.org/message-id/flat/CAD21AoAfOZvmfR0j8VmZorZjL7RhTiQdVttNuC4W-Shdc2a-AA%40mail.gmail.com

- Improve autovacuum tuning
http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com
http://www.postgresql.org/message-id/20130124215715.GE4528@alvh.no-ip.org

I'm kind of on the fence about these. The title is way too broad, and
I doubt we are going to forget to keep improving this area.

It seems the first thread is really about auto-analyze thresholds, so
maybe it should be in a separate entry if we want to do anything
mentioned in the thread?

The second thread is really about autovacuum launcher scheduling.
Probably still relevant, but the thread is very long and doesn't seem
terribly helpful to someone trying to get up to speed on the issues
that are still relevant. I don't see any more recent discussion,
either. Thoughts?

-- 
John Naylor
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Allow escape in application_name
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Appetite for Frama-C annotations?