1. 21 Feb, 1998 1 commit
    • Marc G. Fournier's avatar
      Change: · aa7244ed
      Marc G. Fournier authored
      #define TAPETEMP                "pg_btsortXXXXXX"
      
      to:
      
      #define TAPETEMP                "pg_btsortXXXXXXX"
      
      For some reason, under FreeBSD, it appears that the mktemp() value needs the
      extra 'X' to improve/ensure uniqueness
      aa7244ed
  2. 13 Jan, 1998 1 commit
    • Marc G. Fournier's avatar
      Some *very* major changes by darrenk@insightdist.com (Darren King) · 374bb5d2
      Marc G. Fournier authored
      ==========================================
      What follows is a set of diffs that cleans up the usage of BLCKSZ.
      
      As a side effect, the person compiling the code can change the
      value of BLCKSZ _at_their_own_risk_.  By that, I mean that I've
      tried it here at 4096 and 16384 with no ill-effects.  A value
      of 4096 _shouldn't_ affect much as far as the kernel/file system
      goes, but making it bigger than 8192 can have severe consequences
      if you don't know what you're doing.  16394 worked for me, _BUT_
      when I went to 32768 and did an initdb, the SCSI driver broke and
      the partition that I was running under went to hell in a hand
      basket. Had to reboot and do a good bit of fsck'ing to fix things up.
      
      The patch can be safely applied though.  Just leave BLCKSZ = 8192
      and everything is as before.  It basically only cleans up all of the
      references to BLCKSZ in the code.
      
      If this patch is applied, a comment in the config.h file though above
      the BLCKSZ define with warning about monkeying around with it would
      be a good idea.
      
      Darren  darrenk@insightdist.com
      
      (Also cleans up some of the #includes in files referencing BLCKSZ.)
      ==========================================
      374bb5d2
  3. 07 Jan, 1998 1 commit
  4. 05 Jan, 1998 1 commit
  5. 18 Sep, 1997 1 commit
  6. 08 Sep, 1997 3 commits
  7. 07 Sep, 1997 1 commit
  8. 19 Aug, 1997 1 commit
  9. 12 Aug, 1997 1 commit
  10. 06 Jun, 1997 1 commit
  11. 30 May, 1997 1 commit
  12. 18 Apr, 1997 1 commit
  13. 16 Apr, 1997 1 commit
    • Vadim B. Mikheev's avatar
      1. BTREE_VERSION_1: using bti_itup->t_tid as unique identifier for a given · 329fb112
      Vadim B. Mikheev authored
      index tuple (logical position within A LEVEL). bti_oid & bti_dummy
      taken off from BTItemData.
      2. Fix for multi-column indices (nbtsearch.c):
         _bt_binsrch() - for searches on internal pages having keysize <
      	number of attrs we point at the last item < the scankey, not at the
      	first item = the scankey;
         _bt_moveright() - if keysize < number of attrs we compare scankey with
      	_last_ item on current page to decide should we move right or
      	not.
      329fb112
  14. 24 Mar, 1997 1 commit
    • Vadim B. Mikheev's avatar
      + NULLs handling · 14f6b387
      Vadim B. Mikheev authored
      	Actually required by multi-column indices support.
      	We still don't use btree for 'A is (not) null', but
      	now btree keep items with NULL attrs using single rule
      	for placing/finding items on pages:
      	NULLs greater NOT_NULLs and NULL = NULL.
      + Bulkload code (nbtsort.c) support for multi-column indices
      	building and NULLs.
      + Fix for btendscan()->pfree(scanopaque) from Chris Dunlop.
      14f6b387
  15. 25 Feb, 1997 1 commit
  16. 22 Feb, 1997 1 commit
  17. 14 Feb, 1997 1 commit
  18. 12 Feb, 1997 1 commit
    • Marc G. Fournier's avatar
      What looks like some *major* improvements to btree indexing... · 5d9f146c
      Marc G. Fournier authored
      Patches from: aoki@CS.Berkeley.EDU (Paul M. Aoki)
      
      i gave jolly my btree bulkload code a long, long time ago but never
      gave him a bunch of my bugfixes.  here's a diff against the 6.0
      baseline.
      
      for some reason, this code has slowed down somewhat relative to the
      insertion-build code on very small tables.  don't know why -- it used
      to be within about 10%.  anyway, here are some (highly unscientific!)
      timings on a dec 3000/300 for synthetic tables with 10k, 100k and
      1000k tuples (basically, 1mb, 10mb and 100mb heaps).  'c' means
      clustered (pre-sorted) inputs and 'u' means unclustered (randomly
      ordered) inputs.  the 10k table basically fits in the buffer pool, but
      the 100k and 1000k tables don't.  as you can see, insertion build is
      fine if you've sorted your heaps on your index key or if your heap
      fits in core, but is absolutely horrible on unordered data (yes,
      that's 7.5 hours to index 100mb of data...) because of the zillions of
      random i/os.
      
      if it doesn't work for you for whatever reason, you can always turn it
      back off by flipping the FastBuild flag in nbtree.c.  i don't have
      time to maintain it.
      
      good luck!
      
      baseline code:
      
      time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
      real   8.6
      time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
      real   9.1
      time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
      real   59.2
      time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
      real   652.4
      time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
      real   636.1
      time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
      real   26772.9
      
      bulkloading code:
      
      time psql -c 'create index c10 on k10 using btree (c int4_ops)' bttest
      real   11.3
      time psql -c 'create index u10 on k10 using btree (b int4_ops)' bttest
      real   10.4
      time psql -c 'create index c100 on k100 using btree (c int4_ops)' bttest
      real   59.5
      time psql -c 'create index u100 on k100 using btree (b int4_ops)' bttest
      real   63.5
      time psql -c 'create index c1000 on k1000 using btree (c int4_ops)' bttest
      real   636.9
      time psql -c 'create index u1000 on k1000 using btree (b int4_ops)' bttest
      real   701.0
      5d9f146c
  19. 05 Nov, 1996 1 commit
  20. 03 Nov, 1996 2 commits
  21. 23 Oct, 1996 1 commit
  22. 20 Oct, 1996 1 commit
  23. 18 Oct, 1996 1 commit
  24. 31 Jul, 1996 1 commit
  25. 09 Jul, 1996 1 commit