Message-ID: <3E40493A.DCDD2C4B@Yahoo.com>
Date: Tue, 04 Feb 2003 18:14:02 -0500
From: Jan Wieck <JanWieck@Yahoo.com>
Organization: Home
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christoph Haller <ch@rodos.fzk.de>, pgsql-sql@postgresql.org,
	wweng@kencast.com
Subject: Re: iceberg queries
References: <3E3F7C59.E6C5278C@rodos.fzk.de> <3E40011C.94F11C92@Yahoo.com>
	<15716.1044383829@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> 
> Jan Wieck <JanWieck@Yahoo.com> writes:
> > As to the original question, if an index is available that returns the
> > rows in the sort order of the GROUP BY clause, PostgreSQL defaults to an
> > index scan, otherwise it will do a sort of the rows matching an optional
> > WHERE clause. This sorted set is then grouped and aggregated and
> > filtered by the HAVING clause after aggregation.
> 
> Note that as of 7.4, the planner will probably pick hashed aggregation
> rather than sort-based aggregation, if it can predict that the number
> of groups will not be too large for a hash table to fit in memory.
> This means we can do a seqscan (or, perhaps, an indexscan to match
> WHERE conditions) and avoid sorting.  So I expect performance on this
> type of query to be a good deal better in 7.4.  There are a few
> benchmark comparisons in the pghackers archives a couple months back.
> 
>                         regards, tom lane

If it can predict.

I guess the question was asked because one expects performance problems.
From that I conclude that the amount of data is significant in this
particular case. That does not necessarily but usually mean a large
number of unique groups.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #