Em 25-01-2013 16:29, Jeff Janes escreveu:
On Fri, Jan 25, 2013 at 7:34 AM, alexandre - aldeia digital
wrote:
Hi,
Last weekend, we upgrade a PG from 8.4 to 9.2 version (full
pg_dump/restore/vacuum/analyze). After this, some simple join querys
became very slow, maybe because the use of nested
Hi,
Last weekend, we upgrade a PG from 8.4 to 9.2 version (full
pg_dump/restore/vacuum/analyze). After this, some simple join querys
became very slow, maybe because the use of nested loops. Bellow, an
example with nestedloop on and off:
base=# analyze verbose pc13t;
INFO: analyzing "public.p
Em 13-01-2012 17:08, Josh Berkus escreveu:
On 1/13/12 10:08 AM, alexandre - aldeia digital wrote:
Hi,
Is there a simple way (or a tool) to discover the most searched values
in a field from a table ?
In the pg_stats, I can see the most common values generated by ANALYZE,
but I want to know how
Em 13-01-2012 17:05, Josh Berkus escreveu:
On 1/13/12 2:44 AM, alexandre - aldeia digital wrote:
Also, (2) only really works if you're going to obsolesce (remove)
archive records after a certain period of time. Otherwise the
sub-partitioning hurts performance.
Is there any moves to in
Hi,
Is there a simple way (or a tool) to discover the most searched values
in a field from a table ?
In the pg_stats, I can see the most common values generated by ANALYZE,
but I want to know how many queries are using this values. With this
information and the other statistics, I want to cr
Also, (2) only really works if you're going to obsolesce (remove)
archive records after a certain period of time. Otherwise the
sub-partitioning hurts performance.
Is there any moves to include the "easy" table partitioning in the 9.2
version ?
--
Sent via pgsql-performance mailing list (
I'm not so confident that a RAID-1 will win over a single disk. When it
comes to writes, the latency should be ~50 higher (if both disk must
sync), since the spindles are not running synchronously. This applies to
softraid, not something like a battery-backend raid controller of course.
Or am I w
Em 11-10-2011 15:05, Claudio Freire escreveu:
On Tue, Oct 11, 2011 at 3:02 PM, alexandre - aldeia digital
wrote:
2) Change all memory chips to new others, instead of maintain the old (16
GB) + new (32 GB).
Of course, mixing disables double/triple/whatuple channel, and makes
your memory
Hi,
About 3 hours ago, the client contacted the Dell and they suggested 2
things:
1) Update the baseboard firmware (the only component that haven't
updated yesterday).
2) Change all memory chips to new others, instead of maintain the old
(16 GB) + new (32 GB).
After do this, until now, the
Em 11-10-2011 03:42, Greg Smith escreveu:
On 10/10/2011 01:31 PM, alexandre - aldeia digital wrote:
I drop checkpoint_timeout to 1min and turn on log_checkpoint:
<2011-10-10 14:18:48 BRT >LOG: checkpoint complete: wrote 6885 buffers
(1.1%); 0 transaction log file(s) added, 0 remo
Em 10-10-2011 23:19, Claudio Freire escreveu:
On Tue, Oct 11, 2011 at 12:02 AM, Samuel Gendler
wrote:
The original question doesn't actually say that performance has gone down,
only that cpu utilization has gone up. Presumably, with lots more RAM, it is
blocking on I/O a lot less, so it isn't
Em 10-10-2011 16:39, Kevin Grittner escreveu:
alexandre - aldeia digital wrote:
From the point of view of the client, the question is simple:
until the last friday (with 16 GB of RAM), the load average of
server rarely surpasses 4. Nothing change in normal database use.
Really? The
Em 10-10-2011 14:46, Kevin Grittner escreveu:
alexandre - aldeia digital wrote:
Notice that we have no idle % in cpu column.
So they're making full use of all the CPUs they paid for. That in
itself isn't a problem. Unfortunately you haven't given us nearly
enough info
Em 10-10-2011 11:04, Shaun Thomas wrote:
That's not entirely surprising. The problem with having lots of memory
is... that you have lots of memory. The operating system likes to cache,
and this includes writes. Normally this isn't a problem, but with 48GB
of RAM, the defaults (for CentOS 5.5 in p
Hi,
Yesterday, a customer increased the server memory from 16GB to 48GB.
Today, the load of the server hit 40 ~ 50 points.
With 16 GB, the load not surpasses 5 ~ 8 points.
The only parameter that I changed is effective_cache_size (from 14 GB to
40GB) and shared_buffers (from 1 GB to 5 GB). Set
Em 30-09-2011 14:01, Merlin Moncure escreveu:
2011/9/29 Ondrej Ivanič:
Hi,
On 30 September 2011 01:08, Kevin Grittner wrote:
Is there a suggested number of child tables for table
partitioning,
Generally, don't go over about 100 partitions per table.
Having 365 partitions per table is fine..
Hi,
I am trying the PG 7.4 RC1 and RC2 and I see a superb performance
improvement compared with 7.3
Explaining the querys, I see a change of planner that, in my case,
prefer Nested Loops in 7.4 opposite to Hash or Merge Join in 7.3.
To test, I disable Hash and Merge Joins in 7.3 and performa
Scott, Jeff and Shridhar:
1 GB RAM :)
The stock kernels are not the same, HyperThreading enabled. 80
simultaneous connections. sort_mem = 4096
I will compile my own kernel on this weekend, and I will report
to the list after.
Thank's all
Alexandre
> Also are two kernels exactly same? In my e
Hi,
Old: Post 7.3.2, P4 1.8, 1 MB RAM, 2 x IDE SW RAID 1, RedHat 8
New: Post 7.3.4, Xeon 2.4, 1 MB RAM, 2 x SCSI 15k SW RAID 1, RedHat 9
Both use: Only postgresql on server. Buffers = 8192, effective cache = 10
In old plataform the free and vmstat reports no use of swap.
In new, the swap is
19 matches
Mail list logo
