Message-Id: <199411252313.PAA14212@faerie.CS.Berkeley.EDU>
From: aoki@CS.Berkeley.EDU (Paul M. Aoki)
To: bmcuyper@etro1.vub.ac.be (Bernard De Cuyper)
Cc: postgres-arch@postgres.Berkeley.EDU
Subject: Re: Postgres "main memory/optimisation" 
Reply-To: aoki@CS.Berkeley.EDU (Paul M. Aoki)
In-reply-to: Your message of Fri, 25 Nov 1994 10:37:15 --100 
	     <9411250937.AA12004@etro3.vub.ac.be> 
Date: Fri, 25 Nov 94 15:13:49 -0800
Sender: aoki@postgres.Berkeley.EDU

bmcuyper@etro1.vub.ac.be (Bernard De Cuyper) writes:
> 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

the non-disk storage managers use extra shared memory.  i've never
implemented a storage manager but most of the problems i've observed
have been due to corruption of shared memory -- people don't check
array bounds, etc.

> 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.

postgres has a cost-based optimizer that (like all cost-based
optimizers) depends on accurate statistics.  hence frequent use of
vacuum is recommended (since that's how statistics are updated).  it
uses hash join (good for equijoins), sort-merge join and nested-loop
join (the latter two being what systems like sybase use).  join order
and join algorithm are determined by the optimizer -- there's no
hints, or "syntax-based optimization" as in oracle -- so if your
statistics are out of date, a very suboptimal ordering or algorithm
may be chosen.
--
  Paul M. Aoki          |  University of California at Berkeley
  aoki@CS.Berkeley.EDU  |  Dept. of EECS, Computer Science Division (#1776) 
                        |  Berkeley, CA 94720-1776