| 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
| 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? |
| 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? |