Skip to content
Snippets Groups Projects
  1. Mar 08, 2006
    • Bruce Momjian's avatar
    • Tom Lane's avatar
      Further examination of ltsReleaseBlock usage shows that it's got a · 43ceb3d4
      Tom Lane authored
      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.
      43ceb3d4
  2. Mar 07, 2006
  3. Mar 06, 2006
  4. Mar 05, 2006
  5. Mar 04, 2006
Loading