Re: [HACKERS] A Better External Sort?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Zeugswetter Andreas DAZ SD <ZeugswetterA(at)spardat(dot)at>
Cc: Ron Peacetree <rjpeace(at)earthlink(dot)net>, "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [HACKERS] A Better External Sort?
Date: 2005-10-08 22:51:55
Message-ID: 20051008225155.GA16679@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Thu, Sep 29, 2005 at 03:28:27PM +0200, Zeugswetter Andreas DAZ SD wrote:
>
> > In my original example, a sequential scan of the 1TB of 2KB
> > or 4KB records, => 250M or 500M records of data, being sorted
> > on a binary value key will take ~1000x more time than reading
> > in the ~1GB Btree I described that used a Key+RID (plus node
> > pointers) representation of the data.
>
> Imho you seem to ignore the final step your algorithm needs of
> collecting the
> data rows. After you sorted the keys the collect step will effectively
> access the
> tuples in random order (given a sufficiently large key range).
>
> This random access is bad. It effectively allows a competing algorithm
> to read the
> whole data at least 40 times sequentially, or write the set 20 times
> sequentially.
> (Those are the random/sequential ratios of modern discs)

True, but there is a compromise... not shuffling full tuples around when
sorting in memory. Do your sorting with pointers, then write the full
tuples out to 'tape' if needed.

Of course the other issue here is that as correlation improves it
becomes better and better to do full pointer-based sorting.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-10-08 23:34:21 Re: Vote needed: revert beta2 changes or not?
Previous Message Jim C. Nasby 2005-10-08 22:10:31 Re: pg_dump option to dump only functions

Browse pgsql-performance by date

  From Date Subject
Next Message Announce 2005-10-10 03:03:33 What's the cost of a few extra columns?
Previous Message mark 2005-10-08 13:34:32 Re: count(*) using index scan in "query often, update rarely" environment