We have gotten very good performance from netapp and postgres 7.4.11 .
I was able to push about 100MB/s over gigE, but that was limited by
our netapp.
DAS will generally always be faster, but if for example you have 2
disks vs. 100 NFS mounted ,NFS will be faster.
NFS is very reliable and
On Wed, Apr 26, 2006 at 07:35:42PM -0700, Steve Wampler wrote:
> On Wed, Apr 26, 2006 at 10:06:58PM -0400, Ketema Harris wrote:
> > I was wondering if there were any performance issues with having a data
> > directory that was an nfs mounted drive? Say like a SAN or NAS device? Has
> > anyone done
On Wed, Apr 26, 2006 at 10:06:58PM -0400, Ketema Harris wrote:
> I was wondering if there were any performance issues with having a data
> directory that was an nfs mounted drive? Say like a SAN or NAS device? Has
> anyone done this before?
My understanding is that NFS is pretty poor in performa
On Wed, Apr 26, 2006 at 05:37:31PM -0500, Jim C. Nasby wrote:
> On Wed, Apr 26, 2006 at 06:16:46PM -0400, Bruce Momjian wrote:
> > AMD transfers the dirty cache line directly from cpu to cpu. I can
> > imaging that helping our test-and-set shared memory usage quite a bit.
> Wasn't the whole point
Stef:
There is already a post explaining the solution. All the proper
indexes were there, and it works great on 7.4. The problem lies with
leftover 7.4 RI triggers being carried over to an 8.1 database. The
solution is to drop the triggers and add the constraint. Hopefully
this will n
Title: Running on an NFS Mounted Directory
I was wondering if there were any performance issues with having a data directory that was an nfs mounted drive? Say like a SAN or NAS device? Has anyone done this before?
On Wed, Apr 26, 2006 at 04:33:40PM -0700, Luke Lonergan wrote:
I¹m thinking about it, we¹re already using a fixed read-ahead of 16MB using
blockdev on the stock Redhat 2.6.9 kernel, it would be nice to not have to
set this so we may try it.
FWIW, I never saw much performance difference from doi
Hey there Will,
I would assume that, perhaps, jst perhaps, the FK doesn't have an
index on the field on both sides, so, your seeing a potential sequential
scan happening. Can you fling up an explain anaylze for everyone please
? Anything more will be merely shooting in the dark, and, tracer bu
Title: Re: [Bizgres-general] [PERFORM] Introducing a new linux readahead framework
Jim,
I’m thinking about it, we’re already using a fixed read-ahead of 16MB using blockdev on the stock Redhat 2.6.9 kernel, it would be nice to not have to set this so we may try it.
- Luke
On 4/26/06 3:28 PM
Backpatched to 8.0.X and 8.1.X.
---
Kris Jurka wrote:
>
>
> On Fri, 24 Mar 2006, Jim C. Nasby wrote:
>
> > On Wed, Mar 22, 2006 at 02:37:28PM -0500, Kris Jurka wrote:
> >>
> >> On Wed, 22 Mar 2006, Jim C. Nasby wrote:
> >
On Wed, Apr 26, 2006 at 06:16:46PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Apr 26, 2006 at 10:27:18AM -0500, Scott Marlowe wrote:
> > > If you haven't actually run a heavy benchmark of postgresql on the two
> > > architectures, please don't make your decision based on other
>
(including bizgres-general)
Has anyone done any testing on bizgres? It's got some patches that
eliminate a lot of IO bottlenecks, so it might present even larger
gains.
On Wed, Apr 26, 2006 at 03:08:59PM -0500, Steve Poe wrote:
> I found an average 14% improvement Using Pg 7.4.11 with odbc-bench
On Wed, Apr 26, 2006 at 02:48:53AM -0400, [EMAIL PROTECTED] wrote:
> You said that DB accesses are random. I'm not so sure. In PostgreSQL,
> are not the individual pages often scanned sequentially, especially
> because all records are variable length? You don't think PostgreSQL
> will regularly rea
Jim C. Nasby wrote:
> On Wed, Apr 26, 2006 at 10:27:18AM -0500, Scott Marlowe wrote:
> > If you haven't actually run a heavy benchmark of postgresql on the two
> > architectures, please don't make your decision based on other
> > benchmarks. Since you've got both a D920 and an X2 3800, that'd be a
On Tue, Apr 25, 2006 at 11:07:17PM -0400, Ron Peacetree wrote:
> A minor point to be noted in addition here is that most DB servers under load
> are limited by their physical IO subsystem, their HDs, and not the speed of
> their RAM.
I think if that were the only consideration we wouldn't be see
On Wed, Apr 26, 2006 at 10:17:58AM -0500, Scott Marlowe wrote:
> On Tue, 2006-04-25 at 18:55, Jim C. Nasby wrote:
> > On Tue, Apr 25, 2006 at 01:33:38PM -0500, Scott Marlowe wrote:
> > > On Tue, 2006-04-25 at 13:14, Bill Moran wrote:
> > > > I've been given the task of making some hardware recommen
On Wed, Apr 26, 2006 at 10:27:18AM -0500, Scott Marlowe wrote:
> If you haven't actually run a heavy benchmark of postgresql on the two
> architectures, please don't make your decision based on other
> benchmarks. Since you've got both a D920 and an X2 3800, that'd be a
> great place to start. Mo
I found an average 14% improvement Using Pg 7.4.11 with odbc-bench as my
test bed with Wu's kernel patch. I have not tried version 8.x yet.
Thanks Wu.
Steve Poe
Using Postgresql 7.4.11, on an dual Opteron with 4GB
On Fri, 2006-04-21 at 09:38 +0800, Wu Fengguang wrote:
> Greetings,
>
> I'd li
On Tue, 2006-04-25 at 20:17, [EMAIL PROTECTED] wrote:
> On Tue, Apr 25, 2006 at 08:54:40PM -0400, [EMAIL PROTECTED] wrote:
> > I made the choice I describe based on a lot of research. I was going
> > to go both Intel, until I noticed that the Intel prices were dropping
> > fast. 30% price cut in 2
David Boreham wrote:
It isn't only Postgres. I work on a number of other server applications
that also run much faster on Opterons than the published benchmark
figures would suggest they should. They're all compiled with gcc4,
so possibly there's a compiler issue. I don't run Windows on any
of ou
On Tue, 2006-04-25 at 18:55, Jim C. Nasby wrote:
> On Tue, Apr 25, 2006 at 01:33:38PM -0500, Scott Marlowe wrote:
> > On Tue, 2006-04-25 at 13:14, Bill Moran wrote:
> > > I've been given the task of making some hardware recommendations for
> > > the next round of server purchases. The machines to
Have a look at this Wikipedia page which outlines some differences
between the AMD and Intel versions of 64-bit :
http://en.wikipedia.org/wiki/EM64T
It isn't only Postgres. I work on a number of other server applications
that also run much faster on Opterons than the published benc
Mea Culpa. There is a mistake in my example for SDR vs DDR vs DDR2.
This is what I get for posting before my morning coffee.
The base latency for all of the memory types is that of the base clock rate;
200MHz= 5ns in my given examples.
I double factored, making DDR and DDR2 worse than they actu
From my initial testing this is very promising for a postgres server.
Benchmark-wise, a simple dd with an 8k blocksize gets ~200MB/s as
compared to ~140MB/s on the same hardware without the patch. Also, that
200MB/s seems to be unaffected by the dd blocksize, whereas without the
patch a 512k bl
>While in general there may not be that much of a % difference between
the 2 chips,
>there's a huge gap in Postgres. For whatever reason, Postgres likes
Opterons.
>Way more than Intel P4-architecture chips.
It isn't only Postgres. I work on a number of other server applications
that also run
It was on my first email.
Here it is again:
MONSOON=# explain delete from scenario where id='1099'; QUERY PLAN-- Index Scan using scenario_pkey on scenario (cost=
0.00..3.14 rows=1 width=6)
[EMAIL PROTECTED] wrote:
I have an Intel Pentium D 920, and an AMD X2 3800+. These are very
close in performance. The retail price difference is:
Intel Pentium D 920 is selling for $310 CDN
AMD X2 3800+is selling for $347 CDN
Anybody who claims that Intel is 2X more exp
The reason AMD is has held off from supporting DDR2 until now are:
1. DDR is EOL. JEDEC is not ratifying any DDR faster than 200x2 while DDR2
standards as fast as 333x4 are likely to be ratified (note that Intel pretty
much avoided DDR, leaving it to AMD, while DDR2 is Intel's main RAM tech
I'm posting this to the entire performance list in the hopes that it will be
generally useful.
=r
-Original Message-
>From: [EMAIL PROTECTED]
>Sent: Apr 26, 2006 3:25 AM
>To: Ron Peacetree <[EMAIL PROTECTED]>
>Subject: Re: [PERFORM] Large (8M) cache vs. dual-core CPUs
>
>Hi Ron:
>
>As a r
29 matches
Mail list logo
