Re: [HACKERS] A Better External Sort?

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: "Hannu Krosing" <hannu(at)skype(dot)net>, "Josh Berkus" <josh(at)agliodbs(dot)com>
Cc: "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org, "Michael Stone" <mstone+postgres(at)mathom(dot)us>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [HACKERS] A Better External Sort?
Date: 2005-10-03 21:52:27
Message-ID: BF66F62B.108A0%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hannu,

On 10/3/05 2:43 PM, "Hannu Krosing" <hannu(at)skype(dot)net> wrote:

> Just FYI, I run a count(*) on a 15.6GB table on a lightly loaded db and
> it run in 163 sec. (Dual opteron 2.6GHz, 6GB RAM, 6 x 74GB 15k disks in
> RAID10, reiserfs). A little less than 100MB sec.

This confirms our findings - sequential scan is CPU limited at about 120MB/s
per single threaded executor. This is too slow for fast file systems like
we're discussing here.

Bizgres MPP gets 250MB/s by running multiple scanners, but we still chew up
unnecessary amounts of CPU.

> After this I ran count(*) over a 2.4GB file from another tablespace on
> another device (4x142GB 10k disks in RAID10) and it run 22.5 sec on
> first run and 12.5 on second.

You're getting caching effects here.

- Luke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Stone 2005-10-03 21:53:32 Re: [HACKERS] A Better External Sort?
Previous Message Simon Riggs 2005-10-03 21:51:32 Re: [PERFORM] A Better External Sort?

Browse pgsql-performance by date

  From Date Subject
Next Message Michael Stone 2005-10-03 21:53:32 Re: [HACKERS] A Better External Sort?
Previous Message Simon Riggs 2005-10-03 21:51:32 Re: [PERFORM] A Better External Sort?