Another PGINDENT run that changes variable indenting and case label indenting.  Also static variable indenting.

when btree used in innerscan with run-time key which value
passed by pointer.

Fix: keys ordering stuff moved to _bt_first().

Pointed by Thomas Lockhart.

building.

	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.

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

unique index implementation).

Unallocate opaque.

Changes:

        * Unique index capability works using the syntax 'create unique
          index'.

        * Duplicate OID's in the system tables are removed.  I put
          little scripts called 'duplicate_oids' and 'find_oid' in
          include/catalog that help to find and remove duplicate OID's.
          I also moved 'unused_oids' from backend/catalog to
          include/catalog, since it has to be in the same directory
          as the include files in order to work.

        * The backend tries converting the name of a function or aggregate
          to all lowercase if the original name given doesn't work (mostly
          for compatibility with ODBC).

        * You can 'SELECT NULL' to your heart's content.

        * I put my _bt_updateitem fix in instead, which uses
          _bt_insertonpg so that even if the new key is so big that
          the page has to be split, everything still works.

        * All literal references to system catalog OID's have been
          replaced with references to define'd constants from the catalog
          header files.

        * I added a couple of node copy functions.  I think this was a
          preliminary attempt to get rules to work.

cleaning up behind myself before *yawn* bed :)

My guess is that the thing had bugs, and the pfree was commented out.
The thing is probabally free'ed anyway at the end, so it was not a bad
thing.

If it does cause a bug, it will generate an error when hit, so I say
unless someone else knows, let's remove it and run the regression test.

-Bruce

>   INDEXED searches in some cases DO NOT WORK.
>   Although simple search expressions (i.e. with a constant value on
> the right side of an operator) work, performing a join (by putting
> a field of some other table on the right side of an operator) produces
> empty output.
>   WITHOUT indices, everything works fine.
>

submitted by: "Vadim B. Mikheev" <root@ais.sable.krasnoyarsk.su>