public inbox for [email protected]
help / color / mirror / Atom feedPostgreSQL 8.0.3 Documentation - Chapter 21. Routine Database Maintenance Tasks
11+ messages / 4 participants
[nested] [flat]
* PostgreSQL 8.0.3 Documentation - Chapter 21. Routine Database Maintenance Tasks
@ 2005-07-17 12:04 Halley Pacheco de Oliveira <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-17 12:04 UTC (permalink / raw)
To: pgsql-docs
21.3. Log File Maintenance
It is written:
"Another production-grade approach to managing log output is to send it all to syslog and let
syslog deal with file rotation. To do this, set the configuration parameter log_destination to
syslog (to log to syslog only) in postgresql.conf. Then you can send a SIGHUP signal to the syslog
daemon whenever you want to force it to start writing a new log file. If you want to automate log
rotation, the logrotate program can be configured to work with log files from syslog."
First is said: "send it all to syslog and let syslog deal with file rotation"
Later is said: "If you want to automate log rotation, the logrotate program can be configured to
work with log files from syslog"
So, how syslog deals with file rotation if it is necessary to use the logrotate program to
automate log rotation (working with log files from syslog)?
This paragraph is not clear to me. As I understant syslog doesn't deal with log rotation,
logrotate deals with syslog's log rotation.
The command kill -s SIGHUP `cat /var/run/syslogd.pid` just writes the line "Jul 17 07:55:54
localhost syslogd 1.4.1: restart." in the "/var/log/messages" file, reads the configuartion file,
closes and open this file again in Fedora Core 3 standard configuration. It doesn't write a new
log file.
Regards,
Halley
__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/
^ permalink raw reply [nested|flat] 11+ messages in thread
* PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
@ 2005-07-26 10:06 Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-26 10:06 UTC (permalink / raw)
To: pgsql-docs
In PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity - 23.1. Standard Unix
Tools is written:
The user, database, and connection source host items remain the same for the life of the client
connection, but the activity indicator changes.
But look at that:
psql -U sistemas -h 192.168.0.1 template1
ps aux | grep ^postgres
postgres 3908 0.0 0.3 19948 2000 ? S 05:45 0:00 /usr/bin/postmaster -p 5432 -D
/var/lib/pgsql/data
postgres 3968 0.0 0.3 10748 1792 ? S 05:45 0:00 postgres: stats buffer process
postgres 3969 0.0 0.3 9756 1848 ? S 05:45 0:00 postgres: stats collector process
postgres 8223 0.0 0.5 20348 2608 ? S 06:42 0:00 postgres: sistemas template1
192.168.0.1 idle
template1=# \c teste
ps aux | grep ^postgres
postgres 3908 0.0 0.3 19948 2000 ? S 05:45 0:00 /usr/bin/postmaster -p 5432 -D
/var/lib/pgsql/data
postgres 3968 0.0 0.3 10748 1792 ? S 05:45 0:00 postgres: stats buffer process
postgres 3969 0.0 0.3 9756 1848 ? S 05:45 0:00 postgres: stats collector process
postgres 8244 0.0 0.5 20348 2608 ? S 06:43 0:00 postgres: sistemas teste
192.168.0.1 idle
So the database name didn't remain the same, neither the process id. Connecting to another
database creates a brand new connection using other server process as it seems to be. I think it
should be written in this paragraph. I couldn't imagine that, for me the process was still the
same.
Regards,
Halley
__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
@ 2005-07-26 10:33 ` Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Peter Eisentraut @ 2005-07-26 10:33 UTC (permalink / raw)
To: Halley Pacheco de Oliveira <[email protected]>; +Cc: pgsql-docs
Am Dienstag, 26. Juli 2005 12:06 schrieb Halley Pacheco de Oliveira:
> The user, database, and connection source host items remain the same for
> the life of the client connection, but the activity indicator changes.
> So the database name didn't remain the same, neither the process id.
> Connecting to another database creates a brand new connection using other
> server process as it seems to be. I think it should be written in this
> paragraph. I couldn't imagine that, for me the process was still the same.
What is the problem here? You create a new connection, so you get the
information in the new connection, as documented.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
@ 2005-07-26 13:48 ` Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-26 13:48 UTC (permalink / raw)
To: pgsql-docs; +Cc: Peter Eisentraut <[email protected]>
There is no problem, just a surprise. Once I was connected to one database I didn't expect that a
connection to another database inside psql would close one process and fork a new process. Once
the chapter is about Monitoring Database Activity, I think that it would be good to alert the
readers about this fact. Maybe other users dont't expect this fact too. Just that.
Regards,
Halley
--- Peter Eisentraut <[email protected]> escreveu:
> Am Dienstag, 26. Juli 2005 12:06 schrieb Halley Pacheco de Oliveira:
> > The user, database, and connection source host items remain the same for
> > the life of the client connection, but the activity indicator changes.
>
> > So the database name didn't remain the same, neither the process id.
> > Connecting to another database creates a brand new connection using other
> > server process as it seems to be. I think it should be written in this
> > paragraph. I couldn't imagine that, for me the process was still the same.
>
> What is the problem here? You create a new connection, so you get the
> information in the new connection, as documented.
>
> --
> Peter Eisentraut
> http://developer.postgresql.org/~petere/
>
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis.
Instale o discador agora! http://br.acesso.yahoo.com/
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
@ 2005-07-26 15:26 ` Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Roman Neuhauser @ 2005-07-26 15:26 UTC (permalink / raw)
To: Halley Pacheco de Oliveira <[email protected]>; +Cc: pgsql-docs; Peter Eisentraut <[email protected]>
# [email protected] / 2005-07-26 13:48:55 +0000:
> --- Peter Eisentraut <[email protected]> escreveu:
>
> > Am Dienstag, 26. Juli 2005 12:06 schrieb Halley Pacheco de Oliveira:
> > > The user, database, and connection source host items remain the same for
> > > the life of the client connection, but the activity indicator changes.
> >
> > > So the database name didn't remain the same, neither the process id.
> > > Connecting to another database creates a brand new connection using other
> > > server process as it seems to be. I think it should be written in this
> > > paragraph. I couldn't imagine that, for me the process was still the same.
> >
> > What is the problem here? You create a new connection, so you get the
> > information in the new connection, as documented.
>
> There is no problem, just a surprise. Once I was connected to one database I didn't expect that a
> connection to another database inside psql would close one process and fork a new process. Once
> the chapter is about Monitoring Database Activity, I think that it would be good to alert the
> readers about this fact. Maybe other users dont't expect this fact too. Just that.
If anywhere, such information would belong to the psql(1)
documentation, where it already is:
\connect (or \c) [ dbname [ username ] ]
Establishes a connection to a new database and/or under a user
name. The previous connection is closed.
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
@ 2005-07-26 17:17 ` Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-26 17:17 UTC (permalink / raw)
To: pgsql-docs; +Cc: Roman Neuhauser <[email protected]>
What surprises me is not that the previous connection is closed and a new connection is opened.
What surprises me is the fact that the previous process is killed and a new process is forked just
to connect to another database with the same user. I was expecting that the new connection could
use the same process. If you are monitoring user activity you must know that when the user
connects to another database another process is created, or even worst, if the user connects to
the same database again another process is created.
psql -U sistemas -h 192.168.0.1 teste
ps aux | grep ^postgres
postgres 3910 0.0 0.3 20320 2000 ? S 10:31 0:00 /usr/bin/postmaster -p 5432 -D
/var/lib/pgsql/data
postgres 3968 0.0 0.3 11120 1792 ? S 10:31 0:00 postgres: stats buffer process
postgres 3969 0.0 0.3 10128 1844 ? S 10:31 0:00 postgres: stats collector process
postgres 14006 0.0 0.5 20720 2640 ? S 14:08 0:00 postgres: sistemas teste
192.168.0.1 idle
teste=# \c teste
ps aux | grep ^postgres
postgres 3910 0.0 0.3 20320 2000 ? S 10:31 0:00 /usr/bin/postmaster -p 5432 -D
/var/lib/pgsql/data
postgres 3968 0.0 0.3 11120 1792 ? S 10:31 0:00 postgres: stats buffer process
postgres 3969 0.0 0.3 10128 1844 ? S 10:31 0:00 postgres: stats collector process
postgres 14038 0.0 0.5 20720 2608 ? S 14:09 0:00 postgres: sistemas teste
192.168.0.1 idle
It was not clear to me this relationship between connection and process. Now it is.
Regards,
Halley
--- Roman Neuhauser <[email protected]> escreveu:
>
> If anywhere, such information would belong to the psql(1)
> documentation, where it already is:
>
> \connect (or \c) [ dbname [ username ] ]
> Establishes a connection to a new database and/or under a user
> name. The previous connection is closed.
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis.
Instale o discador agora! http://br.acesso.yahoo.com/
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
@ 2005-07-26 19:49 ` Roman Neuhauser <[email protected]>
2005-07-27 01:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
0 siblings, 1 reply; 11+ messages in thread
From: Roman Neuhauser @ 2005-07-26 19:49 UTC (permalink / raw)
To: Halley Pacheco de Oliveira <[email protected]>; +Cc: pgsql-docs
# [email protected] / 2005-07-26 14:17:17 -0300:
> What surprises me is not that the previous connection is closed and a
> new connection is opened.
> What surprises me is the fact that the previous process is killed and
> a new process is forked just to connect to another database with the
> same user. I was expecting that the new connection could use the same
> process. If you are monitoring user activity you must know that when
> the user connects to another database another process is created, or
> even worst, if the user connects to the same database again another
> process is created.
> It was not clear to me this relationship between connection and
> process. Now it is.
Well, there's nothing that would make this model required, but it
surely helps keep things like entropy at reasonable levels.
IOW, this behavior allows for greater stability through simpler code
and limited process lifetime.
But maybe I'm not understanding the point you're trying to make.
To make things a bit clearer: what is it that you find so disturbing
or surprising in the current PostgreSQL behavior? Why did you expect
it reusing the same process, and what benefits do you expect (or
preferably, have experimentally gained) from the alternative?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
@ 2005-07-27 01:17 ` Halley Pacheco de Oliveira <[email protected]>
2005-07-27 01:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 04:01 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Alvaro Herrera <[email protected]>
0 siblings, 2 replies; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-27 01:17 UTC (permalink / raw)
To: pgsql-docs; +Cc: Roman Neuhauser <[email protected]>
The surprise is:
Oracle - MTS - Multi-Threaded-Server - MTS allows many user processes to share very few server
processes. Without MTS, each user process requires its own dedicated server process; a new server
process is created for each client requesting a connection. A dedicated server process remains
associated to the user process for the remainder of the connection. With MTS many user processes
connect to a dispatcher process. The dispatcher routes client requests to the next available
shared server process. The advantage of MTS is that system overhead is reduced, so the number of
users that can be supported is increased.
Contrasting with this in PostgreSQL a new process is forked just to connect to another database.
The PostgreSQL behavior seems similar to old Oracle versions.
Regards,
Halley
--- Roman Neuhauser <[email protected]> escreveu:
>
> Well, there's nothing that would make this model required, but it
> surely helps keep things like entropy at reasonable levels.
> IOW, this behavior allows for greater stability through simpler code
> and limited process lifetime.
>
> But maybe I'm not understanding the point you're trying to make.
> To make things a bit clearer: what is it that you find so disturbing
> or surprising in the current PostgreSQL behavior? Why did you expect
> it reusing the same process, and what benefits do you expect (or
> preferably, have experimentally gained) from the alternative?
>
_______________________________________________________
Yahoo! Acesso Grátis - Internet rápida e grátis.
Instale o discador agora! http://br.acesso.yahoo.com/
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 01:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
@ 2005-07-27 01:33 ` Roman Neuhauser <[email protected]>
1 sibling, 0 replies; 11+ messages in thread
From: Roman Neuhauser @ 2005-07-27 01:33 UTC (permalink / raw)
To: Halley Pacheco de Oliveira <[email protected]>; +Cc: pgsql-docs
# [email protected] / 2005-07-26 22:17:12 -0300:
> --- Roman Neuhauser <[email protected]> escreveu:
> > But maybe I'm not understanding the point you're trying to make.
> > To make things a bit clearer: what is it that you find so disturbing
> > or surprising in the current PostgreSQL behavior? Why did you expect
> > it reusing the same process, and what benefits do you expect (or
> > preferably, have experimentally gained) from the alternative?
>
> The surprise is:
>
> Oracle - MTS - Multi-Threaded-Server - MTS allows many user processes
> to share very few server processes. Without MTS, each user process
> requires its own dedicated server process; a new server process is
> created for each client requesting a connection. A dedicated server
> process remains associated to the user process for the remainder of
> the connection. With MTS many user processes connect to a dispatcher
> process. The dispatcher routes client requests to the next available
> shared server process. The advantage of MTS is that system overhead is
> reduced, so the number of users that can be supported is increased.
I came to PostgreSQL from MySQL, which is multithreaded, and found
PostgreSQL absolutely UNsurprising in this aspect. There's quite
a few populare programs that behave similarly.
> Contrasting with this in PostgreSQL a new process is forked just to
> connect to another database. The PostgreSQL behavior seems similar to
> old Oracle versions.
So what? Is this a troll?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 01:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
@ 2005-07-27 04:01 ` Alvaro Herrera <[email protected]>
2005-07-27 12:35 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
1 sibling, 1 reply; 11+ messages in thread
From: Alvaro Herrera @ 2005-07-27 04:01 UTC (permalink / raw)
To: Halley Pacheco de Oliveira <[email protected]>; +Cc: pgsql-docs; Roman Neuhauser <[email protected]>
On Tue, Jul 26, 2005 at 10:17:12PM -0300, Halley Pacheco de Oliveira wrote:
> The surprise is:
>
> Oracle - MTS - Multi-Threaded-Server - MTS allows many user processes
> to share very few server processes. Without MTS, each user process
> requires its own dedicated server process; a new server process is
> created for each client requesting a connection. A dedicated server
> process remains associated to the user process for the remainder of
> the connection. With MTS many user processes connect to a dispatcher
> process. The dispatcher routes client requests to the next available
> shared server process. The advantage of MTS is that system overhead is
> reduced, so the number of users that can be supported is increased.
Hmm, seems a very similar thing can be had in Postgres by means of
pgpool.
It'd be interesting to see how are cursors handled, or any other
long-lived session-local resources for that matter, by this dispatcher
process of Oracle's.
--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"Crear es tan difícil como ser libre" (Elsa Triolet)
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 01:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-27 04:01 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Alvaro Herrera <[email protected]>
@ 2005-07-27 12:35 ` Halley Pacheco de Oliveira <[email protected]>
0 siblings, 0 replies; 11+ messages in thread
From: Halley Pacheco de Oliveira @ 2005-07-27 12:35 UTC (permalink / raw)
To: pgsql-docs; +Cc: Alvaro Herrera <[email protected]>; Roman Neuhauser <[email protected]>
--- Alvaro Herrera <[email protected]> escreveu:
>
> Hmm, seems a very similar thing can be had in Postgres by means of
> pgpool.
>
You're right. Using a JDBC connection pool to cache database connections, reuse physical
connections and minimize expensive operations in the creation and closing of database sessions
(1), or pgpool that is a connection pool server for PostgreSQL (2), the overhead of create a
server process for each new connection almost disappears.
It will only be necessary one connection pool for each database accessed, and pgpool will make a
new connection if there's no user name and database name pair yet.
Once more the middle tier simplifies the database operation.
Regards,
Halley
(1)
http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/9i_jdbc/OCIMidAuthSample/Read...
(2) http://pgpool.projects.postgresql.org/
__________________________________________________
Converse com seus amigos em tempo real com o Yahoo! Messenger
http://br.download.yahoo.com/messenger/
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2005-07-27 12:35 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-07-17 12:04 PostgreSQL 8.0.3 Documentation - Chapter 21. Routine Database Maintenance Tasks Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:06 PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 10:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Peter Eisentraut <[email protected]>
2005-07-26 13:48 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 15:26 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-26 17:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-26 19:49 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 01:17 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
2005-07-27 01:33 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Roman Neuhauser <[email protected]>
2005-07-27 04:01 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Alvaro Herrera <[email protected]>
2005-07-27 12:35 ` Re: PostgreSQL 8.0.3 Documentation - Chapter 23. Monitoring Database Activity Halley Pacheco de Oliveira <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox