Subject: Fast Path

From: PostGres <[email-masked]>
Date: Wed, 8 Sep 1993 18:33:21 +1000 (EST)

To those who know far more than I,

I have set up several tables in postgres, and am concerned
with the speed of retrieval that I am getting when doing
large retrieves across the network.

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.

I turned to the manual and read the section on FastPath
and this seemed the way to go, but the lack of description
made it fairly rough going.

Can someone point me in the right direction to begin solving
my problem.

Thanx in advance
Glen.
-- 
--------------------------------------------------------
| University Of Western Sydney                         |
| Postgres Database Aministration                      |
|                                                      |
| Administrator :  Glen Darby                          |
|                                                      |
|                                                      |
| Return Mail : [email-masked]          |
========================================================

---

From: [email-masked] (Paul M. Aoki)
Date: Wed, 08 Sep 93 10:53:44 -0700

> Can someone point me in the right direction to begin solving

(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  |  [email-masked]
                |  Berkeley, CA 94720           |  ...!uunet!ucbvax!aoki