On Wednesday, April 10, 2013, Nik Tek wrote:
Hi Bambi,
Thank you the prompt reply.
This table is very volatile, lot of inserts/updates happen on this
tables(atleast 20~30 inserts/min).
That number of inserts per minute is not all that many. I suspect that you
have sessions which are
On 11/04/13 22:09, Thiyagarajan, Palaniappan wrote:
All,
We have performance issue in Psql8.3 vacuum run. The CPU usage going
300+ and application getting slow. How do we avoid high cpu and
smooth vacuum tables.
I'm afraid this isn't nearly enough information for anyone to help.
1. Full
Hi guys.
I compiled my postrges server (9.1.4) with default segment size (16MB).
Should it be enough? Should I increase this size in compilation?
Hi,
(I have put the contents of this email at http://pastebin.com/6h49zrYE
for better readibility)
I have been circling around the following problem for a few hours and
I am wondering if anyone has any suggestions about why the the second
query is taking so much longer than the first.
Both
On Apr 12, 2013, at 9:45 AM, Rodrigo Barboza wrote:
Hi guys.
I compiled my postrges server (9.1.4) with default segment size (16MB).
Should it be enough? Should I increase this size in compilation?
Unlike some default values in the configuration file, the compiled-in defaults
work well for
On Fri, Apr 12, 2013 at 2:52 PM, Ben Chobot be...@silentmedia.com wrote:
On Apr 12, 2013, at 9:45 AM, Rodrigo Barboza wrote:
Hi guys.
I compiled my postrges server (9.1.4) with default segment size (16MB).
Should it be enough? Should I increase this size in compilation?
Unlike some
On 04/12/2013 11:51 AM, brick pglists wrote:
- Index Scan Backward using event_20130405_id_pk on
event_20130405 e (cost=0.00..612732.34 rows=1889715 width=34) (actual
time=2076.812..2111.274 rows=10100 loops=1)
Filter: ((tstamp_utc = '2013-04-05
Hi Shaun,
On Fri, Apr 12, 2013 at 12:59 PM, Shaun Thomas stho...@optionshouse.com wrote:
On 04/12/2013 11:51 AM, brick pglists wrote:
Since it doesn't show up in your GUC list, you should probably increase your
default_statistics_target to 400 or more, analyze, and try again. The
heuristics
Hi,
What is the recommended swap space for postgres or 9.0.11 or 9.2.3 on
linux(3.0.58-0.6)
RAM on the hox is 32GB.
Thank you
Nik
My experience is that you're best off either with a swap space that matches
or exceeds physical memory, or none at all. The linux kernel swap daemon
(kswapd) gets confused and behaves badly with small swap spaces, especially
the more memory you have. Good news is that hard drives are cheap and 32G
On Fri, Apr 12, 2013 at 6:15 PM, Scott Marlowe scott.marl...@gmail.com wrote:
The really messed up bit is that the problems with the kswapd won't show up
for weeks, months, or sometimes even longer. The symptoms of a kswapd
problem is that swap is mostly full, but there's LOTS of free memory /
Hi guys.
I read in some forums that this parameter is better to set it to something
like 0.7.
Mine is default (0.5) and sometime it logs the message:
WARNING: pgstat wait timeout
Could there be any relation between this parameter and the warning message?
Is it safe to set it to 0.7?
No, I've had it happen with NUMA turned off. The NUMA issues are with
zone_reclaim_mode. If you have it set to 1 (default on a lot of big
machines) it can cause serious problems with performance as well.
On Fri, Apr 12, 2013 at 3:21 PM, Claudio Freire klaussfre...@gmail.comwrote:
On Fri, Apr
On Friday, April 12, 2013, Rodrigo Barboza wrote:
Hi guys.
I compiled my postrges server (9.1.4) with default segment size (16MB).
Should it be enough? Should I increase this size in compilation?
To recommend that you deviate from the defaults, we would have to know
something about your
On Thursday, April 11, 2013, Steve Singer wrote:
I think the reason why it is picking the hash join based plans is because
of
Index Scan using table_b_1_ptid_orgid_ym_unq on table_b_1 b
(cost=0.00..503.86 rows=1 width=10) (actual time=0.016..0.017 rows=1
loops=414249)
15 matches
Mail list logo
