Re: [HACKERS] An introduction and a plea ...

Chris Bitmead wrote:
> 
> Hannu Krosing wrote:
> 
> >   2. a way to go from OID to tuple
> >
> >     The must efficient solution seems to be a file with a simple structure
> > that
> >     has records of (TUPLE_OID,TABLE_OID) wher a record is added at each
> > insert.
> >     As this file is ordered wrt. TULE_OID and has fixed size records, it can
> >     be efficiently searche with binary search. As it is append-only it is also
> >     quite (probably most) efficient on inserts. I can't think of any solutions
> >     using current structures which would be nearly as efficient.
> 
> If you have your suggested indexes that apply over multiple relations, I
> can't see why that can't be used for this too.

The insert performance would be much worse for indexes than for append-only
file.

> It just means that if you use ODBMS it is recommended that you do a 
> CREATE INDEX oid_idx ON object (oid), where "object"
> is a conceptual super-class of all other objects.
> 
> Your append-only file would grow without limit, which I think is a bit
> of a problem for some apps.

I meant vacuum to compress it (which AFAIK it does not do for indexes
currently)

> Also the way ODBMS will work is an application will ask for a chunk
> of oids from the database, some of which may be later "wasted".(This is
> how Versant works and it is also a technique documented by Stonebraker in
> his postgres papers). This technique is so that applications don't have to
> talk to the backend to create objects in the front end that need oids.
> This means objects may not be created with oids in order.
> So you have to store space for oids in your file that may not be used.

Yes, it needs some more book-keeping than I thought (keep the oid-file pages 
that could possibly be updated  in memory until the front-end which requested
the oids disconnects), or just assume all oids will be used and compress the 
unused ones below watermark out in VACUUM.

> I think we need first more conventional style index that works well.
> Then we can experiment with more radical ideas.

An index spanning multiple tables is quite radical anyway. Initially we could 
get by with multiple indexes and extra (but slow) check for uniqueness (when 
index is unique).

> 
> >     The same kind of file could be used for re_introducing time-travel in an
> >     efficient way.
> 
> How?

By writing (TID,TIMESTAMP) tuples there and using that info to retrieve tuples 
active at specified time by examinimg TIDs in "deleted" tuples.
As bot TID and TIMESTAMP should be monotonuously growing again binary search 
can be used on retrieve and inserts are append-only (meaning fast)

Both cases assume that we are oriented on fast inserts, as b-tree would
probably 
be faster than binary search on retrieves, but is much slower on inserts.

> 
> >   5. become even more object-oriented and add methods to tables that can do
> >     different things depending on which table they operate on.
> 
> Does this definitely not work now?

AFAIK functions are selected based on their arguments which can be either a
full 
tuple or several simple types, but not both.

So the first kind _may_ actually work, we must ask someone more familiar on
when 
the actual function is selected for "SELECT T.func() from TAB* T" queries.

--------------
Hannu