Re: Fast insertion indexes: why no developments

Поиск
Список
Период
Сортировка
От Leonardo Francalanci
Тема Re: Fast insertion indexes: why no developments
Дата
Msg-id 1383639934893-5776963.post@n5.nabble.com
обсуждение исходный текст
Ответ на Re: Fast insertion indexes: why no developments  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Fast insertion indexes: why no developments  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-hackers
Andres Freund-3 wrote
> On 2013-11-04 11:27:33 -0500, Robert Haas wrote:
>> On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire <

> klaussfreire@

> > wrote:
>> > Such a thing would help COPY, so maybe it's worth a look
>> 
>> I have little doubt that a deferred insertion buffer of some kind
>> could help performance on some workloads, though I suspect the buffer
>> would have to be pretty big to make it worthwhile on a big COPY that
>> generates mostly-random insertions.
> 
> Even for random data presorting the to-be-inserted data appropriately
> could result in much better io patterns.

Mmh, I'm afraid that the buffer should be huge to get some real advantage.
You have to buffer enough values to avoid "touching" entire pages, which is
not that easy. The LSM-tree is much complicated than a simple memory-buffer
+ delayed inserts. The other index types that are supposed to help in the
random-insertion workload rely on sequential insertions (at the expense of
more writing, and slower reads) rather than re-use the btree pattern.




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



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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Fast insertion indexes: why no developments
Следующее
От: Leonardo Francalanci
Дата:
Сообщение: Re: Fast insertion indexes: why no developments