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
* 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 lse
On Wed, Oct 6, 2010 at 9:30 PM, Stephen Frost 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 a couple 2
* 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..
Ivan Voras 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() or write
On Wed, Oct 6, 2010 at 6:31 PM, Ivan Voras 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 place to
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 an
On Wed, Oct 6, 2010 at 5:31 PM, Ivan Voras 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 place to
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 poss
On Wed, Oct 6, 2010 at 10:22 AM, Sander, Ingo (NSN - DE/Munich)
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 mailing list (pgsql-
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; pgsql-per
On Wed, Oct 6, 2010 at 1:39 AM, Sander, Ingo (NSN - DE/Munich)
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.
yeah -- however
12 matches
Mail list logo
