1. 27 Jun, 2006 1 commit
    • Tom Lane's avatar
      Extend the MinimalTuple concept to tuplesort.c, thereby reducing the · cdd5178c
      Tom Lane authored
      per-tuple space overhead for sorts in memory.  I chose to replace the
      previous patch that tried to write out the bare minimum amount of data
      when sorting on disk; instead, just dump the MinimalTuples as-is.  This
      wastes 3 to 10 bytes per tuple depending on architecture and null-bitmap
      length, but the simplification in the writetup/readtup routines seems
      worth it.
      cdd5178c
  2. 23 May, 2006 1 commit
    • Tom Lane's avatar
      Tweak writetup_heap/readtup_heap to avoid storing the tuple identity · 7f52e0c5
      Tom Lane authored
      and transaction visibility fields of tuples being sorted.  These are
      always uninteresting in a tuple being sorted (if the fields were actually
      selected, they'd have been pulled out into user columns beforehand).
      This saves about 24 bytes per row being sorted, which is a useful savings
      for any but the widest of sort rows.  Per recent discussion.
      7f52e0c5
  3. 10 Mar, 2006 1 commit
    • Tom Lane's avatar
      Recent changes in memory management in tuplesort.c had a problem: the · c65ab0bf
      Tom Lane authored
      case where we run low on array slots before we run low on memory is much
      more probable than I had thought, and so it's important to treat each
      tape fairly in that case.  To fix this, track per-tape slot allocations
      just like we track per-tape space allocation.  Also, in the FINALMERGE
      code path avoid scanning all the input tapes when we really only need to
      read from one.  This should fix poor behavior with very large work_mem
      as exhibited by Stefan Kaltenbrunner.
      I didn't do anything about putting an upper bound on the number of tapes,
      but maybe we should still consider that.
      c65ab0bf
  4. 08 Mar, 2006 1 commit
  5. 07 Mar, 2006 1 commit
    • Tom Lane's avatar
      Repair old performance bug in tuplesort.c/logtape.c. In the case where · 8db05ba4
      Tom Lane authored
      we are doing the final merge pass on-the-fly, and not writing the data
      back onto a 'tape', the number of free blocks in the tape set will become
      large, leading to a lot of time wasted in ltsReleaseBlock().  There is
      really no need to track the free blocks anymore in this state, so add a
      simple shutoff switch.  Per report from Stefan Kaltenbrunner.
      8db05ba4
  6. 05 Mar, 2006 1 commit
  7. 04 Mar, 2006 1 commit
  8. 26 Feb, 2006 1 commit
  9. 19 Feb, 2006 2 commits
    • Tom Lane's avatar
      Update obsolete comment. · 21e2544a
      Tom Lane authored
      21e2544a
    • Tom Lane's avatar
      Improve tuplesort.c to support variable merge order. The original coding · df700e6b
      Tom Lane authored
      with fixed merge order (fixed number of "tapes") was based on obsolete
      assumptions, namely that tape drives are expensive.  Since our "tapes"
      are really just a couple of buffers, we can have a lot of them given
      adequate workspace.  This allows reduction of the number of merge passes
      with consequent savings of I/O during large sorts.
      
      Simon Riggs with some rework by Tom Lane
      df700e6b
  10. 05 Jan, 2006 1 commit
  11. 22 Nov, 2005 1 commit
  12. 20 Nov, 2005 1 commit
  13. 25 Oct, 2005 1 commit
  14. 18 Oct, 2005 1 commit
  15. 15 Oct, 2005 1 commit
  16. 03 Oct, 2005 1 commit
  17. 23 Sep, 2005 1 commit
  18. 25 May, 2005 1 commit
  19. 06 May, 2005 1 commit
  20. 22 Mar, 2005 1 commit
  21. 02 Feb, 2005 1 commit
  22. 31 Dec, 2004 1 commit
    • PostgreSQL Daemon's avatar
      · 2ff50159
      PostgreSQL Daemon authored
      Tag appropriate files for rc3
      
      Also performed an initial run through of upgrading our Copyright date to
      extend to 2005 ... first run here was very simple ... change everything
      where: grep 1996-2004 && the word 'Copyright' ... scanned through the
      generated list with 'less' first, and after, to make sure that I only
      picked up the right entries ...
      2ff50159
  23. 29 Aug, 2004 2 commits
  24. 17 Mar, 2004 1 commit
    • Tom Lane's avatar
      During btree index build, sort equal-keyed tuples according to their · fbac1272
      Tom Lane authored
      TID (heap position).  This doesn't do anything to the validity of the
      finished index, but by pretending to qsort() that there are no really
      equal keys in the sort, we can avoid performance problems with qsort
      implementations that have trouble with large numbers of equal keys.
      Patch from Manfred Koizar.
      fbac1272
  25. 03 Feb, 2004 1 commit
    • Tom Lane's avatar
      Rename SortMem and VacuumMem to work_mem and maintenance_work_mem. · 391c3811
      Tom Lane authored
      Make btree index creation and initial validation of foreign-key constraints
      use maintenance_work_mem rather than work_mem as their memory limit.
      Add some code to guc.c to allow these variables to be referenced by their
      old names in SHOW and SET commands, for backwards compatibility.
      391c3811
  26. 29 Nov, 2003 1 commit
    • PostgreSQL Daemon's avatar
      · 969685ad
      PostgreSQL Daemon authored
      $Header: -> $PostgreSQL Changes ...
      969685ad
  27. 12 Nov, 2003 1 commit
    • Tom Lane's avatar
      Cross-data-type comparisons are now indexable by btrees, pursuant to my · fa5c8a05
      Tom Lane authored
      pghackers proposal of 8-Nov.  All the existing cross-type comparison
      operators (int2/int4/int8 and float4/float8) have appropriate support.
      The original proposal of storing the right-hand-side datatype as part of
      the primary key for pg_amop and pg_amproc got modified a bit in the event;
      it is easier to store zero as the 'default' case and only store a nonzero
      when the operator is actually cross-type.  Along the way, remove the
      long-since-defunct bigbox_ops operator class.
      fa5c8a05
  28. 09 Nov, 2003 1 commit
    • Tom Lane's avatar
      Add operator strategy and comparison-value datatype fields to ScanKey. · c1d62bfd
      Tom Lane authored
      Remove the 'strategy map' code, which was a large amount of mechanism
      that no longer had any use except reverse-mapping from procedure OID to
      strategy number.  Passing the strategy number to the index AM in the
      first place is simpler and faster.
      This is a preliminary step in planned support for cross-datatype index
      operations.  I'm committing it now since the ScanKeyEntryInitialize()
      API change touches quite a lot of files, and I want to commit those
      changes before the tree drifts under me.
      c1d62bfd
  29. 17 Aug, 2003 1 commit
    • Tom Lane's avatar
      Create a 'type cache' that keeps track of the data needed for any particular · ec646dbc
      Tom Lane authored
      datatype by array_eq and array_cmp; use this to solve problems with memory
      leaks in array indexing support.  The parser's equality_oper and ordering_oper
      routines also use the cache.  Change the operator search algorithms to look
      for appropriate btree or hash index opclasses, instead of assuming operators
      named '<' or '=' have the right semantics.  (ORDER BY ASC/DESC now also look
      at opclasses, instead of assuming '<' and '>' are the right things.)  Add
      several more index opclasses so that there is no regression in functionality
      for base datatypes.  initdb forced due to catalog additions.
      ec646dbc
  30. 04 Aug, 2003 2 commits
  31. 25 Jul, 2003 1 commit
  32. 13 May, 2003 1 commit
  33. 13 Nov, 2002 1 commit
  34. 11 Nov, 2002 1 commit
  35. 10 Nov, 2002 1 commit
  36. 31 Oct, 2002 1 commit
  37. 04 Oct, 2002 1 commit
    • Tom Lane's avatar
      Tweak a few of the most heavily used function call points to zero out · 3b8ba163
      Tom Lane authored
      just the significant fields of FunctionCallInfoData, rather than MemSet'ing
      the whole struct to zero.  Unused positions in the arg[] array will
      thereby contain garbage rather than zeroes.  This buys back some of the
      performance hit from increasing FUNC_MAX_ARGS.  Also tweak tuplesort.c
      code for more speed by marking some routines 'inline'.  All together
      these changes speed up simple sorts, like count(distinct int4column),
      by about 25% on a P4 running RH Linux 7.2.
      3b8ba163