To: Gregory Stark <gsstark@mit.edu>
cc: Alvaro Herrera <alvherre@commandprompt.com>,
	Luke Lonergan <llonergan@greenplum.com>,
	Chad Wagner <chad.wagner@gmail.com>, Simon Riggs <simon@2ndquadrant.com>,
	Igor Lobanov <ilobanov@swsoft.com>, Richard Huxton <dev@archonet.com>,
	pgsql-performance@postgresql.org
Subject: Re: Querying distinct values from a large table 
In-reply-to: <877iv3miqu.fsf@stark.xeocode.com> 
References: <C1E49CB9.199A4%llonergan@greenplum.com>
	<87d54wmpvd.fsf@stark.xeocode.com>
	<20070130170443.GJ2303@alvh.no-ip.org>
	<16278.1170222919@sss.pgh.pa.us> <877iv3miqu.fsf@stark.xeocode.com>
Comments: In-reply-to Gregory Stark <gsstark@mit.edu>
	message dated "31 Jan 2007 08:24:41 -0500"
Date: Wed, 31 Jan 2007 10:15:10 -0500
Message-ID: <25904.1170256510@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Gregory Stark <gsstark@mit.edu> writes:
> On the other there are some common situations where you could see
> atypical increases. Consider joining a bunch of small tables to
> generate a large result set. The small tables are probably all in
> memory and the result set may only have a small number of distinct
> values. If you throw out the duplicates early you save *all* the
> I/O. If you have to do a disk sort it could be many orders slower.

Right, we already have support for doing that well, in the form of
hashed aggregation.  What needs to happen is to get that to work for
DISTINCT as well as GROUP BY.  IIRC, DISTINCT is currently rather
thoroughly intertwined with ORDER BY, and we'd have to figure out
some way to decouple them --- without breaking DISTINCT ON, which
makes it a lot harder :-(

			regards, tom lane