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 #
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 |