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... On 8/7/09 5:42 PM, "Scott Marlowe" <scott.marlowe@xxxxxxxxx> wrote: > Oh I just noticed his graphic is "values per second" but he had > originally said they were 16 bit values. Even if they were 32 or 64 > bit values, I'd expect way more than what he's getting there. > > On Fri, Aug 7, 2009 at 6:40 PM, Scott Marlowe<scott.marlowe@xxxxxxxxx> wrote: >> Well, from the article, I got the feeling he never showed up here on >> the list to ask for help, and he just assumed he knew enough about >> postgresql to say it couldn't scale well. I just checked the >> archives, and his name doesn't show up. >> >> When you look at his slides, this one makes we wonder about a few points: >> >> http://deliveryimages.acm.org/10.1145/1540000/1536632/figs/f3.jpg >> > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
