On Mon, Oct 10, 2011 at 3:26 PM, alexandre - aldeia digital
adald...@gmail.com wrote:
Hi,
Yesterday, a customer increased the server memory from 16GB to 48GB.
A shot in the dark... what is the content of /proc/mtrr?
Luca
--
Sent via pgsql-performance mailing list
On Tue, Oct 12, 2010 at 3:07 PM, Jon Nelson jnelson+pg...@jamponi.net wrote:
On Tue, Oct 12, 2010 at 7:27 AM, Mladen Gogala
mladen.gog...@vmsinfo.com wrote:
So, the results weren't cached the first time around. The explanation is the
fact that Oracle, as of the version 10.2.0, reads the table
On Wed, Nov 25, 2009 at 04:22:47PM +0100, marcin mank wrote:
On Tue, Nov 24, 2009 at 2:37 PM, Luca Tettamanti kronos...@gmail.com wrote:
- HashAggregate (cost=1031681.15..1033497.20 rows=181605
width=8) (a
ctual time=571807.575..610178.552 rows=26185953 loops=1)
This is Your
Hello,
I've run in a severe performance problem with the following statement:
DELETE FROM t1 WHERE t1.annotation_id IN (
SELECT t2.annotation_id FROM t2)
t1 contains about 48M record (table size is 5.8GB), while t2 contains about 60M
record (total size 8.6GB). annotation_id is the PK in
On Tue, Nov 24, 2009 at 3:59 PM, Jerry Champlin
jchamp...@absolute-performance.com wrote:
You may want to consider using partitioning. That way you can drop the
appropriate partition and never have the overhead of a delete.
Hum, I don't think it's doable in my case; the partitioning is not
