Re: iceberg queries

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christoph Haller <ch(at)rodos(dot)fzk(dot)de>, pgsql-sql(at)postgresql(dot)org, wweng(at)kencast(dot)com
Subject: Re: iceberg queries
Date: 2003-02-04 23:14:02
Message-ID: 3E40493A.DCDD2C4B@Yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Tom Lane wrote:
>
> Jan Wieck <JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tom Lane 2003-02-04 23:21:28 Re: Serialized Transaction Locking Issues
Previous Message justin 2003-02-04 22:10:06 Serialized Transaction Locking Issues