On Mon, Nov 4, 2013 at 1:09 PM, Robert Haas <[email protected]> wrote: > On Sat, Nov 2, 2013 at 6:07 AM, Simon Riggs <[email protected]> wrote: >> On 29 October 2013 16:10, Peter Geoghegan <[email protected]> wrote: >>> On Tue, Oct 29, 2013 at 7:53 AM, Leonardo Francalanci <[email protected]> >>> wrote: >>>> I don't see much interest in insert-efficient indexes. >>> >>> Presumably someone will get around to implementing a btree index >>> insertion buffer one day. I think that would be a particularly >>> compelling optimization for us, because we could avoid ever inserting >>> index tuples that are already dead when the deferred insertion >>> actually occurs. >> >> That's pretty much what the LSM-tree is. > > What is pretty cool about this sort of thing is that there's no > intrinsic reason the insertion buffer needs to be block-structured or > disk-backed. In theory, you can structure the in-memory portion of > the tree any way you like, using pointers and arbitrary-size memory > allocations and all that fun stuff. You need to log that there's a > deferred insert (or commit to flushing the insertion buffer before > every commit, which would seem to miss the point)
Such a thing would help COPY, so maybe it's worth a look -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
