Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] A Better External Sort?

From: Ron Peacetree <rjpeace(at)earthlink(dot)net>
To: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org,pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] A Better External Sort?
Date: 2005-09-30 20:20:50
Message-ID: 31833713.1128111650174.JavaMail.root@elwamui-polski.atl.sa.earthlink.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
That 11MBps was your =bulk load= speed.  If just loading a table
is this slow, then there are issues with basic physical IO, not just
IO during sort operations.

As I said, the obvious candidates are inefficient physical layout
and/or flawed IO code.

Until the basic IO issues are addressed, we could replace the
present sorting code with infinitely fast sorting code and we'd
still be scrod performance wise.

So why does basic IO suck so badly?

Ron  


-----Original Message-----
From: Josh Berkus <josh(at)agliodbs(dot)com>
Sent: Sep 30, 2005 1:23 PM
To: Ron Peacetree <rjpeace(at)earthlink(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [HACKERS] [PERFORM] A Better External Sort?

Ron,

> Hmmm.
> 60GB/5400secs= 11MBps.  That's ssllooww.  So the first
> problem is evidently our physical layout and/or HD IO layer
> sucks.

Actually, it's much worse than that, because the sort is only dealing 
with one column.  As I said, monitoring the iostat our top speed was 
2.2mb/s.

--Josh


Responses

pgsql-performance by date

Next:From: Jignesh K. ShahDate: 2005-09-30 20:38:00
Subject: Re: [PERFORM] A Better External Sort?
Previous:From: Jim C. NasbyDate: 2005-09-30 19:34:59
Subject: Re: database bloat, but vacuums are done, and fsm seems to be setup ok

pgsql-hackers by date

Next:From: Jignesh K. ShahDate: 2005-09-30 20:38:00
Subject: Re: [PERFORM] A Better External Sort?
Previous:From: Robert TreatDate: 2005-09-30 18:26:02
Subject: Re: Found small issue with OUT params

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group