Changes between Initial Version and Version 1 of Ticket #31202, comment 11


Ignore:
Timestamp:
Feb 28, 2022, 6:16:10 AM (2 years ago)
Author:
jerch

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #31202, comment 11

    initial v1  
    88- `bulk_update` shows much worse runtime behavior than all others (thus accounting is stopped early)
    99- `django-bulk-update` can keep up a bit longer, but then shows the same worse runtime growth (prolly due to the same SQL logic used?). This gets really worse for updates >5k (not shown).
    10 - `copy_update` has a much higher setup costs (1 to 256 updated records)
     10- `copy_update` has much higher setup costs (1 to 256 updated records, kinda expected due to temp table and index creation)
    1111- between 4096 to 8192 updates `copy_update` starts to pay off compared to `fast_update`, at 32k updates it is almost twice as fast
    12 - not shown in the charts: for higher updates counts it keeps gaining ground (almost being 4 times faster for 1M update records)
     12- not shown in the charts: for higher update counts it keeps gaining ground (almost being 4 times faster for 1M update records)
    1313- There is something going on between 256-512 updates, as almost all implementations show a steep jump there (postgres b-tree depth change? did not investigate that further...)
    1414
Back to Top