Re: Big 7.1 open items - Mailing list pgsql-hackers

On Fri, Jun 16, 2000 at 04:27:22PM +0000, Thomas Lockhart wrote:
> > ...  But I think it's critical to keep
> > the low-level file access protocol simple and reliable, which really
> > means minimizing the amount of information the backend needs to know 
> > to figure out which file to write a page in.  With something like the 
> > above you only need to know the tablespace name (or more likely OID), 
> > the relation OID (+name or not, depending on outcome of other 
> > argument), and the offset in the table.  No worse than now from the 
> > software's point of view.
> > Comments?

I think the backend needs a per table token that indicates how
to get at the physical bits of the file. Whether that's a filename
alone, filename with path, oid, key to a smgr hash table or something
else, it's opaque above the smgr routines.

Hmm, now I'm thinking, since the tablespace discussion has been reopened,
the way to go about coding all this is to reactivate the smgr code: how
about I leave the existing md smgr as is, and clone it, call it md2 or
something, and start messing with adding features there?


> 
> I'm probably missing the context a bit, but imho we should try hard to
> stay away from symlinks as the general solution for anything.
> 
> Sorry for being behind here, but to make sure I'm on the right page:
> o tablespaces decouple storage from logical tables
> o a database lives in a default tablespace, unless specified
> o by default, a table will live in the default tablespace
> o (eventually) a table can be split across tablespaces
> 
> Some thoughts:
> o the ability to split single tables across disks was essential for
> scalability when disks were small. But with RAID, NAS, etc etc isn't
> that a smaller issue now?
> o "tablespaces" would implement our less-developed "with location"
> feature, right? Splitting databases, whole indices and whole tables
> across storage is the biggest win for this work since more users will
> use the feature.
> o location information needs to travel with individual tables anyway.

I was juist thinking that that discussion needed some summation.

Some links to historic discussion: 

This one is Vadim saying WAL will need oids names:
http://www.postgresql.org/mhonarc/pgsql-hackers/1999-11/msg00809.html

A longer discussion kicked off by Don Baccus:
http://www.postgresql.org/mhonarc/pgsql-hackers/2000-01/msg00510.html

Tom suggesting OIDs to allow rollback:
http://www.postgresql.org/mhonarc/pgsql-hackers/2000-03/msg00119.html


Martin Neumann posted an question on dataspaces:

(can't find it in the offical archives:  looks like March 2000, 10-29 is
missing. here's my copy: don't beat on it!  n particular, since I threw
it together for local access, it's one _big_ index page)

http://cooker.ir.rice.edu/postgresql/msg20257.html
(in that thread is a post where I mention blindwrites and getting rid
of GetRawDatabaseInfo)

Martin later posted an RFD on tablespaces:

http://cooker.ir.rice.edu/postgresql/msg20490.html

Here's Horák Daniel with a patch for discussion, implementing dataspaces
on a per database level:

http://cooker.ir.rice.edu/postgresql/msg20498.html

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005