From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
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 18:37:09 |
Message-ID: | 15716.1044383829@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-02-04 18:46:45 | Re: pg_views |
Previous Message | Jan Wieck | 2003-02-04 18:06:20 | Re: iceberg queries |