Re: PG-related ACM Article: "The Pathologies of Big Data" - Mailing list pgsql-performance

From Scott Marlowe
Subject Re: PG-related ACM Article: "The Pathologies of Big Data"
Date
Msg-id dcc563d10908072003u1198f170pe8cdcc9387a22302@mail.gmail.com
Whole thread Raw
In response to Re: PG-related ACM Article: "The Pathologies of Big Data"  (Scott Carey <scott@richrelevance.com>)
Responses Re: PG-related ACM Article: "The Pathologies of Big Data"
List pgsql-performance
On Fri, Aug 7, 2009 at 7:34 PM, Scott Carey<scott@richrelevance.com> wrote:
> Well, there is CPU overhead for reading postgres pages and tuples.  On a
> disk subsystem that gets 1GB/sec sequential reads, I can't get more than
> about 700MB/sec of I/O and on a select count(*) query on very large tables
> with large rows (600 bytes) and its closer to 300MB/sec if the rows are
> smaller (75 bytes). In both cases it is CPU bound with little i/o wait and
> disk utilization under 65% in iostat.
>
> I also get over 13GB/sec to RAM from a single thread (Nehalem processor).
>
> I don't see how on any recent hardware, random access to RAM is slower than
> sequential from disk.  RAM access, random or not, is measured in GB/sec...

I don't think anybody's arguing that.

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: PG-related ACM Article: "The Pathologies of Big Data"
Next
From: Robert Haas
Date:
Subject: Re: SQL select query becomes slow when using limit (with no offset)