From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Anuradha Ratnaweera <anuradha(at)lklug(dot)pdn(dot)ac(dot)lk> |
Cc: | pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, anuradha(at)gnu(dot)org |
Subject: | Re: [HACKERS] Group by, count, order by and limit |
Date: | 2003-02-18 13:35:12 |
Message-ID: | 20030218133512.GA11307@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tue, Feb 18, 2003 at 10:26:46 +0600,
Anuradha Ratnaweera <anuradha(at)lklug(dot)pdn(dot)ac(dot)lk> wrote:
>
> My 3rd attempt to post ...
>
> Consider this query on a large table with lots of different IDs:
>
> SELECT id FROM my_table GROUP BY id ORDER BY count(id) LIMIT 10;
>
> It has an index on id. Obviously, the index helps to evaluate count(id)
> for a given value of id, but count()s for all the `id's should be
> evaluated, so sort() will take most of the time.
>
> Is there a way to improve performance of this query? If not, please
> give some indication to do a workaround on the source itself, so perhaps
> I may be able to come out with a patch.
In 7.4 there is a hash method that can be used for aggregates. This
may help a lot in your case if there aren't a lot of distict IDs.
7.4 is a long way from even a beta, but you still might want to play with
it to see if it will solve your problem down the road.
From | Date | Subject | |
---|---|---|---|
Next Message | Shridhar Daithankar<shridhar_daithankar@persistent.co.in> | 2003-02-18 13:43:51 | Re: Handling users |
Previous Message | Colin Mangiagalli | 2003-02-18 13:32:04 | Re: Transaction Logs Recycling Problem |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-02-18 13:46:06 | Re: pg environment? metadata? |
Previous Message | Christoph Haller | 2003-02-18 12:13:30 | Re: pg environment? metadata? |