Hi
# ps -ef | grep idle | wc -l
87
# ps -ef | grep SELECT | wc -l
5
I have 2 web servers which connect to PGPool which connects to our
postgres db. I have noticed that idle connections seem to take up CPU
and RAM (according to top). Could this in any way cause things to slow
down?
--
Hi,
I'm having trouble understanding the cost of the Materialize
operator. Consider the following plan:
Nested Loop (cost=2783.91..33217.37 rows=78634 width=44) (actual
time=77.164..2478.973 rows=309 loops=1)
Join Filter: ((rank2.pre = rank5.pre) AND (rank5.pre =
rank2.post))
On Apr 21, 2008, at 4:50 AM, Adrian Moisey wrote:
Hi
# ps -ef | grep idle | wc -l
87
# ps -ef | grep SELECT | wc -l
5
I have 2 web servers which connect to PGPool which connects to our
postgres db. I have noticed that idle connections seem to take up
CPU and RAM (according to top).
Hi
# ps -ef | grep idle | wc -l
87
[...]
I have 2 web servers which connect to PGPool which connects to our
postgres db. I have noticed that idle connections seem to take up CPU
and RAM (according to top). Could this in any way cause things to
slow down?
Dependant on how much memory
Viktor Rosenfeld [EMAIL PROTECTED] writes:
I'm having trouble understanding the cost of the Materialize
operator. Consider the following plan:
Nested Loop (cost=2783.91..33217.37 rows=78634 width=44) (actual
time=77.164..2478.973 rows=309 loops=1)
Join Filter: ((rank2.pre =
On Apr 21, 2008, at 9:15 AM, Adrian Moisey wrote:
Hi
# ps -ef | grep idle | wc -l
87
[...]
I have 2 web servers which connect to PGPool which connects to our
postgres db. I have noticed that idle connections seem to take up
CPU and RAM (according to top). Could this in any way cause
dforums dforums 'at' vieonet.com writes:
2Q) Here are my settings for vacuum, could you help me to optimise
those settings, at the moment the vacuum analyse sent every night is
taking around 18 h to run, which slow down the server performance.
It's a lot of time for a daily job (and it is
dforums wrote:
Hello,
I need wo advice on vacuum settings.
I have a quad core X5355 @ 2.66GHz with 8 Go of memory
1Q) Why autovaccum does not work, I have set the value to on in
postgresql.conf but when the server start it's still off
You need to turn stats_row_level on too.
# -
On Thursday 27 March 2008 17:11, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Sunday 16 March 2008 22:18, Tom Lane wrote:
Fix TransactionIdIsCurrentTransactionId() to use binary
search instead
of linear search when checking child-transaction XIDs.
Are there
Robert Treat wrote:
Unfortunatly I don't have the 8.1 system to bang on anymore for this, (though
anecdotaly speaking, I never saw this behavior in 8.1) however I do now have
a parallel 8.3 system crunching the data, and it is showing the same symptom
(yes, 2 8.3 servers, crunching the
On Sun, 20 Apr 2008 17:15:36 +0200, Francisco Reyes
[EMAIL PROTECTED] wrote:
PFC writes:
- If you process up to some percentage of your RAM worth of data,
hashing is going to be a lot faster
Thanks for the excellent breakdown and explanation. I will try and get
sizes of the tables in
PFC wrote:
Actually, the memory used by the hash depends on the number of
distinct values, not the number of rows which are processed...
Consider :
SELECT a GROUP BY a
SELECT a,count(*) GROUP BY a
In both cases the hash only holds discinct values. So if you have
1 million rows to
Mark Mielke wrote:
PFC wrote:
Actually, the memory used by the hash depends on the number of
distinct values, not the number of rows which are processed...
Consider :
SELECT a GROUP BY a
SELECT a,count(*) GROUP BY a
In both cases the hash only holds discinct values. So if you
13 matches
Mail list logo
