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

Re: [PERFORM] A Better External Sort?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Peacetree <rjpeace(at)earthlink(dot)net>
Cc: Dann Corbit <DCorbit(at)connx(dot)com>, pgsql-hackers(at)postgresql(dot)org,pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] A Better External Sort?
Date: 2005-09-27 01:42:18
Message-ID: 6141.1127785338@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Ron Peacetree <rjpeace(at)earthlink(dot)net> writes:
> Let's start by assuming that an element is <= in size to a cache line and a
> node fits into L1 DCache.  [ much else snipped ] 

So far, you've blithely assumed that you know the size of a cache line,
the sizes of L1 and L2 cache, and that you are working with sort keys
that you can efficiently pack into cache lines.  And that you know the
relative access speeds of the caches and memory so that you can schedule
transfers, and that the hardware lets you get at that transfer timing.
And that the number of distinct key values isn't very large.

I don't see much prospect that anything we can actually use in a
portable fashion is going to emerge from this line of thought.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Qingqing ZhouDate: 2005-09-27 01:43:14
Subject: Re: Query seem to slow if table have more than 200 million rows
Previous:From: Ron PeacetreeDate: 2005-09-27 01:10:47
Subject: Re: [PERFORM] A Better External Sort?

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2005-09-27 01:48:34
Subject: Re: Database file compatability
Previous:From: Andrew DunstanDate: 2005-09-27 01:27:28
Subject: Re: State of support for back PG branches

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