agora inbox for postgres@postgres.berkeley.edu  

help / color / mirror / Atom feed

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

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: postgres@postgres.berkeley.edu
  Cc: aoki@CS.Berkeley.EDU, bmcuyper@etro1.vub.ac.be, postgres-arch@postgres.Berkeley.EDU
  Subject: Re: Postgres "main memory/optimisation"
  In-Reply-To: <199411252313.PAA14212@faerie.CS.Berkeley.EDU>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox