Re: pgsql: Optimize btree insertions for common case of increasing values

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pgsql: Optimize btree insertions for common case of increasing values
Дата
Msg-id CAH2-Wzm171z4Q7=waBeTRyZp9-JPYwEYLCWWoTvr9_YzCQeEAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Optimize btree insertions for common case of increasing values  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: pgsql: Optimize btree insertions for common case of increasing values  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-committers
On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> I think you can take that wording almost verbatim. Obviously it should
> refer to the optimization by name, and blend into the surrounding text
> in the README. I suggest putting a small section before "On-the-Fly
> Deletion Of Index Tuples", but after the main discussion of deletion +
> recycling. It's essentially an exception to the general rule, so that
> placement makes sense to me.

I also think that we should also say something about extent-based
storage. This optimization relies on the assumption that reading some
stale block cannot read a block from some other relation (which could
perhaps be its own rightmost leaf page). If we ever wanted to share
storage between small relations as extents, that would invalidate the
optimization.

This came up recently on the "PostgreSQL's handling of fsync() errors
is unsafe and risks data loss at least on XFS" thread, and what I
describe is in fact how other database systems manage storage, so this
seems like a real practical consideration.

-- 
Peter Geoghegan


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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: pgsql: Silence some warnings in TAP tests
Следующее
От: Alvaro Herrera
Дата:
Сообщение: pgsql: Fix incorrect logic for choosing the next Parallel Appendsubpla