| From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
|---|---|
| To: | Scott Carey <scott(at)richrelevance(dot)com> |
| Cc: | Josh Kupershmidt <schmiddy(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: PG-related ACM Article: "The Pathologies of Big Data" |
| Date: | 2009-08-08 03:03:45 |
| Message-ID: | dcc563d10908072003u1198f170pe8cdcc9387a22302@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Fri, Aug 7, 2009 at 7:34 PM, Scott Carey<scott(at)richrelevance(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2009-08-08 03:37:35 | Re: SQL select query becomes slow when using limit (with no offset) |
| Previous Message | Scott Carey | 2009-08-08 01:34:41 | Re: PG-related ACM Article: "The Pathologies of Big Data" |