Return-Path: postman 
Delivery-Date: Wed, 08 Sep 93 10:47:19 PDT
Return-Path: postman
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA12671; Wed, 8 Sep 93 10:43:52 -0700
Resent-From: postman (POSTGRES mailing list)
Resent-Message-Id: <9309081743.AA12671@postgres.Berkeley.EDU>
Sender: owner-postman@postgres.Berkeley.EDU
X-Return-Path: aoki@postgres.Berkeley.EDU
Received: from faerie.CS.Berkeley.EDU by postgres.Berkeley.EDU (5.61/1.29)
	id AA12663; Wed, 8 Sep 93 10:43:46 -0700
Received: from localhost (localhost [127.0.0.1]) by faerie.CS.Berkeley.EDU (8.1C/8.1B) with SMTP id KAA19685; Wed, 8 Sep 1993 10:53:45 -0700
Message-Id: <199309081753.KAA19685@faerie.CS.Berkeley.EDU>
From: aoki@postgres.Berkeley.EDU (Paul M. Aoki)
To: PostGres <postgres@st.nepean.uws.edu.au>
Cc: postgres
Subject: Re: Fast Path 
In-Reply-To: Your message of Wed, 8 Sep 1993 18:33:21 +1000 (EST) 
	     <199309080833.AA25499@guinevere.st.nepean.uws.edu.au> 
Date: Wed, 08 Sep 93 10:53:44 -0700
X-Sender: aoki@postgres.Berkeley.EDU
X-Mts: smtp
Resent-To: postgres-dist
Resent-Date: Wed, 08 Sep 93 10:43:50 PDT

> Since the drives where the data is stored is NFS mounted
> to the machine where postgres runs, I would like to access
> the functions that would bring back the tuples directly
> from the file rather than using the postmaster.
> Can someone point me in the right direction to begin solving
> my problem.

(1) once the backend server is forked, your application is talking
to the backend server directly through a tcp connection (think of
the postmaster as being just like inetd).  the backend server runs
on the same host as the postmaster.  so fastpath doesn't help you
"get at the file directly" since your problem is really that the
data manager is not running on the machine where the files are 
(fastpath still involves running in the backend server).

(2) if you move the data manager to the data storage host, you can
use fastpath to reduce the overhead of accessing stuff but there 
is NO support in fastpath for directly grovelling around in the 
files that store classes without using the access methods provided.
(that defeats the whole purpose of using a data manager with 
transactions, buffering, etc.  you may as well use flat files..)

(3) NFS-mounting your data is a big lose, since you are forcing many 
pages to move needlessly from the file server to the backend server 
host before tuples are pulled out of the pages and moved from the 
backend server host to the frontend application host.  if you 
don't index your data carefully and are doing a lot of heap scans,
this will pull all of your data over the network over and over and...

not that postgres is a big speed demon to begin with (understatement),
but if you have a slow network or a heavily-loaded NFS file server you 
will take an even bigger performance hit.

to summarize, you're trying to optimize at too low a level to start
with.  offhand, i suggest looking into 
	(1) moving your data to the host where the postmaster runs
	(2) indexing your data to optimize common queries
if you absolutely cannot do (1), (2) will help anyway.
--
  Paul M. Aoki  |  CS Div., Dept. of EECS, UCB  |  aoki@postgres.Berkeley.EDU
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki