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
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 collector
On Sun, May 29, 2011 at 4:55 PM, Stefan Keller 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 table.
>
>
On Thu, May 26, 2011 at 5:30 PM, Tom Lane 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 pgsql-general m
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
wrote:
> On 05/30/2011 03:26 AM, Edison So wrote:
>
>> Thanks Graig for y
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?!? That
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 :-)
http://www.postgresql.org/docs/curr
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
> t
On Sun, 29 May 2011 23:11:50 +0200,
Thomas Kellerer 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 to rule o
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 info
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.
information_sche
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 maili
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. C
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 thi
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 tak
On 29 May 2011 16:12, Tom Lane wrote:
> Thom Brown writes:
>> On 10 January 2009 19:22, Raymond O'Donnell 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 w
Thom Brown writes:
> On 10 January 2009 19:22, Raymond O'Donnell 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
On 10 January 2009 19:22, Raymond O'Donnell 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 re
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 pe
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.
20 matches
Mail list logo