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

already doing

Removed only reference to a machine.h I could find in c.h, to win32/machine.h

Essentially, config.h now includes an 'os.h', which is created via
configure by linking a "port.h" file from the port directory to the
include directory.

Going to try to merge backend/port in similar ways

aren't doing anything anyway

	sigprocmask, setsid and waitpid

Especially for nextstep systems

Awaiting for a context diff from Gregor to complete changes for the nextstep
port

Add a check to configure for strdup
Remove all the '-ltermcap' checks from psql/Makefile
Have {psql,pg_dump}/Makefile modified if strdup doesn't exist on the system

|by neglecting to quote them.
|
|I have made a minor change to pg_dump.c that will fix this.
|
|Dates are dumped and restored OK with pg_dump in V6
|
|We'll still need to fix the dump in both cases if the original dump is from V1.09.

From Keith Parks

Pointed out by: Erik Bertelsen

Pointed out by D'Arcy

Pointed out by Bruce

Submitted by: Tatsuo Ishii

Remove references to NEED_UNION_SEMUN from include/config.h.in and
from include/storage/ipc.h, replacing it with a single HAVE_UNION_SEMUN

Add CFLAGS= @CPPFLAGS@ to Makefile.global and configure so that build is
	useful for finding extra header files

Split header files from libraries in build.  Doesn't make much sense to
	look for a header file in /usr/local/lib, nor to look for a library
	in /usr/local/include :)

to include inet_aton.c if required

required

Pointed out by Brian E. Gallew

Pointed out by: Darren King

directories to search to find libraries, and then runs ./configure directly

Submitted by: Keith Parks

Change reference to Postgres95 to PostgreSQL in GNUmakefile

clean up some of the readline code in config.h.in

Pointed out by:" Tatsuo Ishii <t-ishii@sra.co.jp>