From: Jeffrey W. Baker <jwbaker@acm.org>
To: Ron Peacetree <rjpeace@earthlink.net>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
Date: Tue, 27 Sep 2005 10:26:28 -0700
Message-ID: <1127841988.8965.3.camel@toonses.gghcwest.com> (raw)
In-Reply-To: <6620549.1127841338151.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
References: <6620549.1127841338151.JavaMail.root@elwamui-polski.atl.sa.earthlink.net>
On Tue, 2005-09-27 at 13:15 -0400, Ron Peacetree wrote:
> That Btree can be used to generate a physical reordering of the data
> in one pass, but that's the weakest use for it. The more powerful
> uses involve allowing the Btree to persist and using it for more
> efficient re-searches or combining it with other such Btrees (either as
> a step in task distribution across multiple CPUs or as a more efficient
> way to do things like joins by manipulating these Btrees rather than
> the actual records.)
Maybe you could describe some concrete use cases. I can see what you
are getting at, and I can imagine some advantageous uses, but I'd like
to know what you are thinking.
Specifically I'd like to see some cases where this would beat sequential
scan. I'm thinking that in your example of a terabyte table with a
column having only two values, all the queries I can think of would be
better served with a sequential scan.
Perhaps I believe this because you can now buy as much sequential I/O as
you want. Random I/O is the only real savings.
-jwb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jwbaker@acm.org, rjpeace@earthlink.net, josh@agliodbs.com, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
In-Reply-To: <1127841988.8965.3.camel@toonses.gghcwest.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox