mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-03 07:27:20 +02:00
43ceb3d449
performance issue during regular merge passes not only the 'final merge' case. The original design contemplated that there would never be more than about one free block per 'tape', hence no need for an efficient method of keeping the free blocks sorted. But given the later addition of merge preread behavior in tuplesort.c, there is likely to be about work_mem worth of free blocks, which is not so small ... and for that matter the number of tapes isn't necessarily small anymore either. So we'd better get rid of the assumption entirely. Instead, I'm assuming that the usage pattern will involve alternation between merge preread and writing of a new run. This makes it reasonable to just add blocks to the list without sorting during successive ltsReleaseBlock calls, and then do a qsort() when we start getting ltsGetFreeBlock() calls. Experimentation seems to confirm that there aren't many qsort calls relative to the number of ltsReleaseBlock/ltsGetFreeBlock calls. |
||
|---|---|---|
| .. | ||
| backend | ||
| bin | ||
| include | ||
| interfaces | ||
| makefiles | ||
| pl | ||
| port | ||
| template | ||
| test | ||
| timezone | ||
| tools | ||
| tutorial | ||
| utils | ||
| bcc32.mak | ||
| DEVELOPERS | ||
| Makefile | ||
| Makefile.global.in | ||
| Makefile.shlib | ||
| nls-global.mk | ||
| win32.mak | ||