Re: PG process architecture

From: "Milen Kulev" <makulev(at)gmx(dot)net>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PG process architecture
Date: 2006-01-11 15:38:34
Message-ID: 949.1136993914@www82.gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Harris,
from oracle DBA point of view Enterprise DB is VERY cool. My boss will be
very happy to hear that there a way to get (paid) support for a PG DB.

But at the end I want to undestand how PG (and its clone Enterprise DB )
is working ;) . Hopefully I don't need to read the whole source of PG
(several times) to understand a little bit deeper the internal mechanics of
PG.

Regards. Milen.

> --- Ursprüngliche Nachricht ---
> Von: "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com>
> An: Milen Kulev <makulev(at)gmx(dot)net>
> Betreff: Re: [HACKERS] PG process architecture
> Datum: Wed, 11 Jan 2006 09:44:31 -0500
>
> As an Oracle DBA, you may want to take a look at EnterpriseDB (
> http://www.enterprisedb.com/)
>
>
> On 1/11/06, Milen Kulev <makulev(at)gmx(dot)net> wrote:
> >
> > Hi listers,
> > I am experienced Oracle DBA und now I was given a task to evaluate
> > Postgresql.
> > May first goal is to compare the architecture of Oracle and Postgres.
> > After reading the fine manuals and several mailing lists, I have found
> > that the following parameters are analogous in
> > PG vs Oracle
> > ------------
> > shared_buffers <-> db_cache_size
> > wal_buffers <-> log_buffer
> >
> > shared_buffers and wal_buffers are residing in shared memory segments.
> > My questions is:
> > Where PG is storing data dictionary information (coming form system pg_*
> > tables)
> > while parsing the queries ?
> > I suppose each each background process is parsing (and eventually
> caching)
> > the parsed SQL
> > statements in his own memory (within each backend process), aka there is
> > no
> > SHARED_POOL as in Oracle.
> > That would mean that backand processes don't have a common place to
> check
> > whether sa same
> > SQL query (with the same planner environment) is already parsed (and
> ready
> > for execution).
> > That would mean that each backend process could reuse only his "own"
> > parsed
> > statements (provided
> > that bind variables are used)
> >
> > Is there any parameter (apart from "geqo_pool_size", I suppose) that
> > limits
> > the size
> > of this "private pool" memory in each backend process?
> >
> >
> > Consider the following scenario.
> > If I have a system with 50 or 100 connection (and the corresponding 100
> > backend processes),
> > and one session creates an index on a given table, how do the other 99
> > processes
> > notice that they can use (or at least estimate the appropriatness of the
> > usage of) the new index ?
> > How PG ist doing this ?
> >
> > I would be very grateful if someone can sched some light /links,
> previous
> > postings, comments/
> > on this topic.
> >
> > Regards, Milen
> >
> > --
> > Telefonieren Sie schon oder sparen Sie noch?
> > NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> >
>

--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse für Mail, Message, More +++

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-01-11 16:02:17 Re: PG process architecture
Previous Message Tom Lane 2006-01-11 15:37:24 Re: PG process architecture