From: | "Shridhar Daithankar<shridhar_daithankar(at)persistent(dot)co(dot)in>" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Group by, count, order by and limit |
Date: | 2003-02-18 05:41:38 |
Message-ID: | 200302181111.38250.shridhar_daithankar@persistent.co.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Tuesday 18 Feb 2003 9:56 am, you 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.
First, what does explain analyze say
Second, wild shot, how much difference does it make with different sort_mem
settings?
Shridhar
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Murtagh | 2003-02-18 06:05:52 | Re: pg_dump --> restore loses constraints/triggers? |
Previous Message | Shridhar Daithankar<shridhar_daithankar@persistent.co.in> | 2003-02-18 05:34:03 | Re: Table Partitioning in Postgres: |
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-02-18 05:47:36 | Re: Non-colliding auto generated names |
Previous Message | Curt Sampson | 2003-02-18 05:37:37 | Re: Detecting corrupted pages earlier |