Re: Fast insertion indexes: why no developments
От | Andres Freund |
---|---|
Тема | Re: Fast insertion indexes: why no developments |
Дата | |
Msg-id | 20131104163248.GH25546@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Fast insertion indexes: why no developments (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Fast insertion indexes: why no developments
Re: Fast insertion indexes: why no developments |
Список | pgsql-hackers |
On 2013-11-04 11:27:33 -0500, Robert Haas wrote: > On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire <klaussfreire@gmail.com> 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. > I think the question is not so > much whether it's worth doing but where anyone's going to find the > time to do it. Yea :( I think doing this outside of s_b will make stuff rather hard for physical replication and crash recovery since we either will need to flush the whole buffer at checkpoints - which is hard since the checkpointer doesn't work inside individual databases - or we need to persist the in-memory buffer across restart which also sucks. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: