Re: PG process architecture

Поиск
Список
Период
Сортировка
От Milen Kulev
Тема Re: PG process architecture
Дата
Msg-id 949.1136993914@www82.gmx.net
обсуждение исходный текст
Ответ на PG process architecture  ("Milen Kulev" <makulev@gmx.net>)
Ответы Re: PG process architecture  ("Joshua D. Drake" <jd@commandprompt.com>)
Список 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.harris@gmail.com>
> An: Milen Kulev <makulev@gmx.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@gmx.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 +++


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: PG process architecture
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: PG process architecture