Re: Inserting heap tuples in bulk in COPY
От | Jesper Krogh |
---|---|
Тема | Re: Inserting heap tuples in bulk in COPY |
Дата | |
Msg-id | 50235FE8.9030802@krogh.cc обсуждение исходный текст |
Ответ на | Re: Inserting heap tuples in bulk in COPY (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Inserting heap tuples in bulk in COPY
|
Список | 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.
В списке pgsql-hackers по дате отправления: