On Wed, Oct 6, 2010 at 1:39 AM, Sander, Ingo (NSN - DE/Munich)
ingo.san...@nsn.com wrote:
Changing of the storage method ( alter table bytea_demo Alter part1 Set
storage EXTERNAL)
or the increasing of the BLOCK_SIZE (new compilation of the code with
--with-blocksize=32) change the behaviour.
Hi,
I thougth I have disabled compressing by setting alter command? Or is
there another command?
BR
Ingo
-Original Message-
From: ext Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, October 06, 2010 2:51 PM
To: Sander, Ingo (NSN - DE/Munich)
Cc: ext Craig Ringer;
On Wed, Oct 6, 2010 at 10:22 AM, Sander, Ingo (NSN - DE/Munich)
ingo.san...@nsn.com wrote:
Hi,
I thougth I have disabled compressing by setting alter command? Or is
there another command?
yes. have you re-run the test? got any performance results?
merlin
--
Sent via pgsql-performance
On 10/04/10 20:49, Josh Berkus wrote:
The other major bottleneck they ran into was a kernel one: reading from
the heap file requires a couple lseek operations, and Linux acquires a
mutex on the inode to do that. The proper place to fix this is
certainly in the kernel but it may be possible to
On Wed, Oct 6, 2010 at 5:31 PM, Ivan Voras ivo...@freebsd.org wrote:
On 10/04/10 20:49, Josh Berkus wrote:
The other major bottleneck they ran into was a kernel one: reading from
the heap file requires a couple lseek operations, and Linux acquires a
mutex on the inode to do that. The proper
All,
There's a number of blog tests floating around comparing XFS and Ext3,
and the various Linux schedulers, for PGDATA or for an all-in-one mount.
However, the WAL has a rather particular write pattern, and it's
reasonable to assume that it shouldn't be optimized the same way as
PGDATA. Has
On Wed, Oct 6, 2010 at 6:31 PM, Ivan Voras ivo...@freebsd.org wrote:
On 10/04/10 20:49, Josh Berkus wrote:
The other major bottleneck they ran into was a kernel one: reading from
the heap file requires a couple lseek operations, and Linux acquires a
mutex on the inode to do that. The proper
Ivan Voras ivo...@freebsd.org writes:
On 10/04/10 20:49, Josh Berkus wrote:
The other major bottleneck they ran into was a kernel one: reading from
the heap file requires a couple lseek operations, and Linux acquires a
mutex on the inode to do that.
Hmmm... lseek? As in lseek() then read()
* Robert Haas (robertmh...@gmail.com) wrote:
Hey, I didn't know about those. That sounds like it might be worth
investigating, though I confess I lack a 48-core machine on which to
measure the alleged benefit.
I've got a couple 24-core systems, if it'd be sufficiently useful to
test with..
On Wed, Oct 6, 2010 at 9:30 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Hey, I didn't know about those. That sounds like it might be worth
investigating, though I confess I lack a 48-core machine on which to
measure the alleged benefit.
I've got
* Robert Haas (robertmh...@gmail.com) wrote:
It's good to be you.
They're HP BL465 G7's w/ 2x 12-core AMD processors and 48G of RAM.
Unfortunately, they currently only have local storage, but it seems
unlikely that would be an issue for this.
I don't suppose you could try to replicate the
As written before I have rerun the test a) without compression and b)
with enlarged BLOCK_SIZE. Result was the same.
BR
Ingo
-Original Message-
From: ext Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Wednesday, October 06, 2010 4:50 PM
To: Sander, Ingo (NSN - DE/Munich)
Cc: ext Craig
12 matches
Mail list logo
