Re: Inserting heap tuples in bulk in COPY
Jesper Krogh <jesper@krogh.cc>
From: Jesper Krogh <jesper@krogh.cc>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Jeff Janes <jeff.janes@gmail.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-08-09T06:59:52Z
Lists: pgsql-hackers
On 08/08/12 21:34, Robert Haas wrote: >> I think we need to implement buffering both to end of statement or end >> of transaction, not just one or the other. > Another (not necessarily better) idea is to use a buffer that's part > of the index, like the GIN fastupdate stuff, so that there's no > particular constraint on when the buffer has to be flushed, but > competing index scans may be slower until it is. If it is an implementation artifact or an result of this approach I dont know. But currently, when the GIN fastupdate code finally decides to "flush" the buffer, it is going to stall all other processes doing updates while doing it. If you only have one update process then this doesn't matter. But if you're trying to get user-interactive-updates to flow in with batch-updates from background processes, then you'd better kill off this feature, since you're gauranteed that the user-interactive process is either going to flush the buffer or wait on someone else doing it. I havent done the benchmarking, but I'm actually fairly sure that fastupdate isn't overall faster if you bump concurrency slightly and run of memory or SSD-based backends due to this cross-backend contention of the buffer. A buffer that is backend local, so you can use transactions to batch up changes would get around this, but that may have another huge set of consequenses I dont know if. ... based on my own real-world experience with this feature.