forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit00d1e02
committed
hio: Use ExtendBufferedRelBy() to extend tables more efficiently
While we already had some form of bulk extension for relations, it was fairlylimited. It only amortized the cost of acquiring the extension lock, therelation itself was still extended one-by-one. Bulk extension was also solelytriggered by contention, not by the amount of data inserted.To address this, use ExtendBufferedRelBy(), introduced in31966b1, toextend the relation. We try to extend the relation by multiple blocks in twosituations:1) The caller tells RelationGetBufferForTuple() that it will need multiple pages. For now that's only used by heap_multi_insert(), see commit FIXME.2) If there is contention on the extension lock, use the number of waiters for the lock as a multiplier for the number of blocks to extend by. This is similar to what we already did. Previously we additionally multiplied the numbers of waiters by 20, but with the new relation extension infrastructure I could not see a benefit in doing so.Using the freespacemap to provide empty pages can cause significantcontention, and adds measurable overhead, even if there is no contention. Toreduce that, remember the blocks the relation was extended by in theBulkInsertState, in the extending backend. In case 1) from above, the blocksthe extending backend needs are not entered into the FSM, as we know that wewill need those blocks.One complication with using the FSM to record empty pages, is that we need toinsert blocks into the FSM, when we already hold a buffer content lock. Toavoid doing IO while holding a content lock, release the content lock beforerecording free space. Currently that opens a small window in which anotherbackend could fill the block, if a concurrent VACUUM records the freespace. If that happens, we retry, similar to the already existing case whenotherBuffer is provided. In the future it might be worth closing the race bypreventing VACUUM from recording the space in newly extended pages.This change provides very significant wins (3x at 16 clients, on myworkstation) for concurrent COPY into a single relation. Even single threadedCOPY is measurably faster, primarily due to not dirtying pages whileextending, if supported by the operating system (see commit4d330a6). Evensingle-row INSERTs benefit, although to a much smaller degree, as the relationextension lock rarely is the primary bottleneck.Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>Discussion:https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de1 parent1cbbee0 commit00d1e02
3 files changed
+233
-144
lines changedLines changed: 2 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1774 | 1774 | | |
1775 | 1775 | | |
1776 | 1776 | | |
| 1777 | + | |
| 1778 | + | |
1777 | 1779 | | |
1778 | 1780 | | |
1779 | 1781 | | |
| |||
0 commit comments
Comments
(0)