Subject: Simple oid question

From: [email-masked] (rich mayfield)
Date: Fri, 21 Feb 92 09:37:10 -0800

I've got a simple oid question:

	How are oid's assigned?  What I'm wondering, do oid's for a
	given record/object uniquely identify the object across just
	the table that it resides in, or is the oid unique across all
	tables in the database?

Question about indices:

	I'm running version 3.0 currently and according to the docs only
	one key is allowed for a given index.  Is this restriction
	lifted in the upcoming 4.0 release?

Thanks for your help.
rich
	
 --------------------------------------------------------
 Rich Mayfield                     Phone: (510)449-6881
 Software Developer                  FAX: (510)449-6885
 Delta Microsystems Inc.           email: [email-masked]

---

From: [email-masked]
Date: Mon, 24 Feb 92 09:32:16 +1100

In response to the news question to comp.database.informix I have
had no reponses except yours info-perl.

Converting oraperl to infoperl would take much, but I'm not a
experienced embeded informix programmer. Also I don't have much time
at the monment.  I might take a look at it later in the year.

Alex Kowalenko
R&D COntractor

||||OTC||

---

From: [email-masked]
Date: Mon, 24 Feb 92 10:15:45 +1100

Please execuse that last message from me, wrong reply address.

Alex Kowalenko

---

From: postarch (Postgres Mailing Archive)
Date: Tue, 25 Feb 92 10:54:41 PST

> 	the table that it resides in, or is the oid unique across all

Oid's are unique across the entire database.

> 	lifted in the upcoming 4.0 release?

No, sorry.

Jeff Meredith
[email-masked]

---

From: [email-masked] (Mike Olson)
Date: Tue, 25 Feb 92 11:27:05 PST

> Oid's are unique across the entire database.

in fact, we have a couple of duplicates in the system catalogs, but not
in places where it matters.  they arose over the years, from people not
being careful about values they chose for new oids.  once you install
the system, no new oid will ever be assigned to more than one object in
the database.

> > 	lifted in the upcoming 4.0 release?

it's possible to define a functional index on two or more attributes,
and get this to work okay.  it's a little convoluted, but here is what
i do in the inversion file system:

	define a new data type, 'oidseq', that consists of an oid and
	    an int4 (sequence number):

		typedef struct oidseq {
		    oid   os_oid;
		    int4  os_seqno;
		} oidseq;

	    and use 'define type' with input and output functions as
	    appropriate;

	define a function mkoidseq() that takes an oid and an int4 and
	    returns an instance of oidseq;

	define a new operator class for btrees called 'oidseq_ops' that
	    handles ordering on oidseqs --  major key is the oid, minor
	    key is the int4;

	finally, define a functional index:

	    define index mao_index on mao_files using btree
		(mkoidseq(foid, fseqno) oidseq_ops)

so with a little trouble, you can get multi-key indices.  the problem
is that the optimizer won't consider them for scans on only one of the
two keys; you need to query explicitly mkoidseq() of an oid,seqno pair.
however, if you plan to run queries of the form

	retrieve mao_files.fdata
	    where mkoidseq(mao_files.foid, mao_files.seqno) >= "10,0"::oidseq
	      and mkoidseq(mao_files.foid, mao_files.seqno) < "11,0"::oidseq

the optimizer does the right thing.  i use these indices for fast multi-key
lookup on data blocks for inversion files.

					mike