Re: Fast insertion indexes: why no developments

Поиск
Список
Период
Сортировка
От Leonardo Francalanci
Тема Re: Fast insertion indexes: why no developments
Дата
Msg-id 1383152048288-5776413.post@n5.nabble.com
обсуждение исходный текст
Ответ на Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
Ответы Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Jeff Janes wrote
> The index insertions should be fast until the size of the active part of
> the indexes being inserted into exceeds shared_buffers by some amount
> (what
> that amount is would depend on how much dirty data the kernel is willing
> to
> allow in the page cache before it starts suffering anxiety about it).  If
> you have enough shared_buffers to make that last for 15 minutes, then you
> shouldn't have a problem inserting with live indexes.

Sooner or later you'll have to checkpoint those shared_buffers... and we are
talking about GB of data (my understanding is that we change basically every
btree page, resulting in re-writing of the whole index).






--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Fast-insertion-indexes-why-no-developments-tp5776227p5776413.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Something fishy happening on frogmouth