On 2013-11-04 11:27:33 -0500, Robert Haas wrote: > On Mon, Nov 4, 2013 at 11:24 AM, Claudio Freire <klaussfre...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers