2015-06-05 deavid <deavidsed...@gmail.com>: > Mode 3: on "aminsert", put the new entry on a second btree; leaving the > first one untouched. Because the second btree is new, will be small, and > writes should be faster. When doing a index scan, read tuples from both at > same time (like merge sort). On vacuum, merge the second btree onto the > first. On this mode, the index is sorted and there's no need of recheck.
You might be interested in reading the thread “Fast insertion indexes: why no developments” (2013), starting at 1383033222.73186.yahoomail...@web172602.mail.ir2.yahoo.com . That thread talks mostly about reducing the (delayed) I/O caused by inserting in a super-big index at a continuously high rate, while you seem more interested in the delay problem caused by the CPU time used when inserting in multiple indexes (which should be quite fast already, as most of the writing is delayed). Your problem (if it is really about delay and not about continuous throughput) might be better served by a delay-reducing solution such as writing a logical “row X is inserted, please make sure that all indexes are up-to-date” to the WAL, instead of the physical “row X is inserted into table A, part Y of index Z must be updated like this, part Q of index S must be updated like so, etc” as is done now. Updating the indexes (not only the writing itself) would then be performed in a delayed fashion. Reading of an index must always additionally scan the in-memory queue of logical WAL records that is kept. Of course, switching the WAL wholesale from a physical description of the changes that must be performed to a logical description is probably not feasible. Therefore, one could think about some new kind of “logical WAL” that gets logged separately (or even mixed in with the normal, physical WAL), where first the logical WAL is written (“insert row X in table A”), after which other operations can continue and the logical WAL is converted to physical WAL asynchronously (by “performing” the changes as is currently done, but by a background process). Recovery then would first need to replay the physical WAL, and then replay the logical WAL. Nicolas -- A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
