On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise people that they might want to
consider it.
On 29/05/2011 4:39 PM, Craig Ringer wrote:
On 29/05/2011 10:44 AM, Edison So wrote:
Can anyone tell me that if the max_connections is above 100, the server
will use pooling instead?
No. PostgreSQL does not have any built-in connection pooling, that was
the point of the suggestion, to advise
On 10 January 2009 19:22, Raymond O'Donnell r...@iol.ie wrote:
On 10/01/2009 19:15, Thom Brown wrote:
I can't find anything in the documentation, but does anyone know if
there is a way to rename a constraint?
I just tried it with a primary key...
test=# alter table t1 alter constraint t1_pk
Thom Brown thombr...@gmail.com writes:
On 10 January 2009 19:22, Raymond O'Donnell r...@iol.ie wrote:
On 10/01/2009 19:15, Thom Brown wrote:
I can't find anything in the documentation, but does anyone know if
there is a way to rename a constraint?
I just tried it with a primary key...
On 29 May 2011 16:12, Tom Lane t...@sss.pgh.pa.us wrote:
Thom Brown thombr...@gmail.com writes:
On 10 January 2009 19:22, Raymond O'Donnell r...@iol.ie wrote:
On 10/01/2009 19:15, Thom Brown wrote:
I can't find anything in the documentation, but does anyone know if
there is a way to rename a
Hi Craig
Thanks for the answer. I also thought about this. You mean something like this?
SELECT reltuples FROM pg_class WHERE relname = 'mytable';
182820 (rows)
That seams reasonably fast compared to count(*).
But I'm hesitating to use ANALYZE for two reasons:
1. It's very slow: it repeadly
Hello,
after configuring a new home server with PostgreSQL 9.0.4, I observe some
regular disk activity, even though the server is completely idle (disconnected
from the network, no users but one logged in). There are very short write
bursts once in about 3 seconds.
There are a couple of
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I have
just started to use Postgres 9.0 with no prior training.
I live in Canada and where I live has no instructor-led training on Postgres
9.0 with replication.
Hi,
I've been scouring the system tables for a way to return a list of
fields across all tables of a database. I see that pg_attribute is the
one to query here, but I'm not sure how to rule out system fields.
Thanks in advance for any pointers.
Cheers,
--
Seb
--
Sent via pgsql-general
Seb wrote on 29.05.2011 23:04:
Hi,
I've been scouring the system tables for a way to return a list of
fields across all tables of a database. I see that pg_attribute is the
one to query here, but I'm not sure how to rule out system fields.
Thanks in advance for any pointers.
On 29 May 2011, at 19:45, Stefan Keller wrote:
But I'm hesitating to use ANALYZE for two reasons:
1. It's very slow: it repeadly takes 59000 ms on my machine.
ANALYZE on a single table takes 59s?!? That's _really_ long. How big is that
table (it has about 180k rows, you did provide that
On Sun, 29 May 2011 23:11:50 +0200,
Thomas Kellerer spam_ea...@gmx.net wrote:
Seb wrote on 29.05.2011 23:04:
Hi,
I've been scouring the system tables for a way to return a list of
fields across all tables of a database. I see that pg_attribute is
the one to query here, but I'm not sure how
Hi Alban
On 2011/5/29 Alban Hertroys wrote:
On 29 May 2011, at 19:45, Stefan Keller wrote:
But I'm hesitating to use ANALYZE for two reasons:
1. It's very slow: it repeadly takes 59000 ms on my machine.
ANALYZE on a single table takes 59s?!? That's _really_ long. How big is that
table (it
On 05/30/2011 03:26 AM, Edison So wrote:
Thanks Graig for your comprehensive explanation although I do not
understanding everything you said such as pgbouncer and pg_connect. I
have just started to use Postgres 9.0 with no prior training.
Google is great :-)
On 05/30/2011 05:55 AM, Stefan Keller wrote:
Hi Alban
On 2011/5/29 Alban Hertroys wrote:
On 29 May 2011, at 19:45, Stefan Keller wrote:
But I'm hesitating to use ANALYZE for two reasons:
1. It's very slow: it repeadly takes 59000 ms on my machine.
ANALYZE on a single table takes 59s?!?
Thank Graig for the links. You have been very helpful.
When I get time, I will definitely read over the materials to get familar
with Postgres.
Have a wonderful night.
Edison
On Sun, May 29, 2011 at 7:27 PM, Craig Ringer
cr...@postnewspapers.com.auwrote:
On 05/30/2011 03:26 AM, Edison So
On Thu, May 26, 2011 at 5:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, maybe word it as If you're considering raising max_connections much
above 100, ... ?
I think it can be even shorter and to the point:
If you're considering raising max_connections consider pooling instead.
--
Sent via
On Sun, May 29, 2011 at 4:55 PM, Stefan Keller sfkel...@gmail.com wrote:
2. There's an autovacuum background process which already does the
job, doesn't it?
Yes, but in its own time. If you know there has been a batch of
inserts/deletes you might as well run analyse immediately on that
On 05/29/2011 02:42 PM, Andrej Podzimek wrote:
I identified the most active process, at least twenty times more
active than any other process on the system:
postgres 3086 0.1 0.0 34688 2584 ?Ss 03:11 1:16
postgres: stats collector process
So it's the statistics
On 28/05/11 18:42, Carl von Clausewitz wrote:
a few months ago, when I installed my first PostgreSQL, I have had the
same problem. I've try to get any information about optimal memory
config, and working, but there wasn't any optimal memory setting
calculator on the internet, just some guide in
20 matches
Mail list logo
