From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
Cc: | "Ron Peacetree" <rjpeace(at)earthlink(dot)net>, pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: [PERFORM] A Better External Sort? |
Date: | 2005-09-29 17:06:52 |
Message-ID: | BF616D3C.104C3%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Josh,
On 9/29/05 9:54 AM, "Josh Berkus" <josh(at)agliodbs(dot)com> wrote:
> Following an index creation, we see that 95% of the time required is the
> external sort, which averages 2mb/s. This is with seperate drives for
> the WAL, the pg_tmp, the table and the index. I've confirmed that
> increasing work_mem beyond a small minimum (around 128mb) had no benefit
> on the overall index creation speed.
Yuuuup! That about sums it up - regardless of taking 1 or 2 passes through
the heap being sorted, 1.5 - 2 MB/s is the wrong number. This is not
necessarily an algorithmic problem, but is a optimization problem with
Postgres that must be fixed before it can be competitive.
We read/write to/from disk at 240MB/s and so 2 passes would run at a net
rate of 120MB/s through the sort set if it were that efficient.
Anyone interested in tackling the real performance issue? (flame bait, but
for a worthy cause :-)
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-09-29 17:17:57 | Re: [PERFORM] A Better External Sort? |
Previous Message | Josh Berkus | 2005-09-29 16:54:05 | Re: [PERFORM] A Better External Sort? |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2005-09-29 17:17:57 | Re: [PERFORM] A Better External Sort? |
Previous Message | Josh Berkus | 2005-09-29 16:54:05 | Re: [PERFORM] A Better External Sort? |