Message-Id: <199411252314.PAA14226@faerie.CS.Berkeley.EDU>
From: aoki@CS.Berkeley.EDU (Paul M. Aoki)
To: postgres-arch@postgres.Berkeley.EDU
Reply-To: aoki@CS.Berkeley.EDU (Paul M. Aoki)
Subject: [bmcuyper@etro1.vub.ac.be: Postgres "main memory/optimisation"]
Date: Fri, 25 Nov 94 15:14:01 -0800
Sender: aoki@postgres.Berkeley.EDU

------- Forwarded Message

 From:  bmcuyper@etro1.vub.ac.be (Bernard De Cuyper)
 To:  aoki@CS.Berkeley.EDU
 Subject:  Postgres "main memory/optimisation"
 Date:  Fri, 25 Nov 1994 10:37:15 --100

 
 Hi,
 
 I have used the "main memory" option, however I would not 
 recommand its use to anyone. It works, but later on, I got stuck
 when a problem occurs, the postgres system was no more able to retrieve 
 the "mirror classes" using the main memory options. Even if the quantity of
 data is small !
 
 > * retrieve (mSlice.all)\g
 
 > Query sent to backend is "retrieve (mSlice.all)"
 > WARN:Nov 25 09:37:00:cannot count blocks for mSlice
 
 Another observation on speed, is that joins are quite slow on large relations even with hashing indexes. I do not know how the postgres is handelling joins internally, a thing which could be helpfull to rewrite queries in a more suitable way.
 
 Sincerely,
 
 Bernard
 bmcuyper@etro.vub.ac.be
 Dep. ETRO/IRIS
 Free University of Brussels(VUB)
 

------- End of Forwarded Message
--
  Paul M. Aoki          |  University of California at Berkeley
  aoki@CS.Berkeley.EDU  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776