PG process architecture

From: "Milen Kulev" <makulev(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: PG process architecture
Date: 2006-01-11 14:42:32
Message-ID: 9140.1136990552@www97.gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-01-11 14:53:42 Re: leaks in TopMemoryContext?
Previous Message ITAGAKI Takahiro 2006-01-11 10:32:43 Overflow of bgwriter's request queue