Re: PG-related ACM Article: "The Pathologies of Big Data"

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: PG-related ACM Article: "The Pathologies of Big Data"
Дата
Msg-id dcc563d10908072003u1198f170pe8cdcc9387a22302@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PG-related ACM Article: "The Pathologies of Big Data"  (Scott Carey <scott@richrelevance.com>)
Ответы Re: PG-related ACM Article: "The Pathologies of Big Data"
Список 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 по дате отправления:

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: PG-related ACM Article: "The Pathologies of Big Data"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: SQL select query becomes slow when using limit (with no offset)