- 21 Feb, 1998 1 commit
-
-
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
-
- 13 Jan, 1998 1 commit
-
-
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.) ==========================================
-
- 07 Jan, 1998 1 commit
-
-
Bruce Momjian authored
-
- 05 Jan, 1998 1 commit
-
-
Bruce Momjian authored
-
- 18 Sep, 1997 1 commit
-
-
Bruce Momjian authored
-
- 08 Sep, 1997 3 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Bruce Momjian authored
Another PGINDENT run that changes variable indenting and case label indenting. Also static variable indenting.
-
- 07 Sep, 1997 1 commit
-
-
Bruce Momjian authored
-
- 19 Aug, 1997 1 commit
-
-
Bruce Momjian authored
-
- 12 Aug, 1997 1 commit
-
-
Bruce Momjian authored
-
- 06 Jun, 1997 1 commit
-
-
Vadim B. Mikheev authored
-
- 30 May, 1997 1 commit
-
-
Vadim B. Mikheev authored
-
- 18 Apr, 1997 1 commit
-
-
Vadim B. Mikheev authored
building.
-
- 16 Apr, 1997 1 commit
-
-
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.
-
- 24 Mar, 1997 1 commit
-
-
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.
-
- 25 Feb, 1997 1 commit
-
-
Marc G. Fournier authored
containing non-unique data
-
- 22 Feb, 1997 1 commit
-
-
Vadim B. Mikheev authored
-
- 14 Feb, 1997 1 commit
-
-
Bruce Momjian authored
-
- 12 Feb, 1997 1 commit
-
-
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
-
- 05 Nov, 1996 1 commit
-
-
Marc G. Fournier authored
-
- 03 Nov, 1996 2 commits
-
-
Marc G. Fournier authored
-
Marc G. Fournier authored
cleaning up behind myself before *yawn* bed :)
-
- 23 Oct, 1996 1 commit
-
-
Marc G. Fournier authored
-
- 20 Oct, 1996 1 commit
-
-
Marc G. Fournier authored
-
- 18 Oct, 1996 1 commit
-
-
Marc G. Fournier authored
found. Document any '#ifdef' segments found in config.h
-
- 31 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
fixes another complaint. More fixes from Bruce...
-
- 09 Jul, 1996 1 commit
-
-
Marc G. Fournier authored
-