From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Shaun Grannis <shaun_grannis(at)hotmail(dot)com> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Performance Issues |
Date: | 2002-04-25 16:42:46 |
Message-ID: | 20020425093313.M65761-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> # EXPLAIN SELECT ln, count(1) FROM data_table GROUP BY ln;
>
> NOTICE: QUERY PLAN:
>
> Aggregate (cost=19538149.27..19864263.69 rows=6522288 width=19)
>
> -> Group (cost=19538149.27..19701206.48 rows=65222884 width=19)
>
> -> Sort (cost=19538149.27..19538149.27 rows=65222884 width=19)
>
> -> Seq Scan on data_table (cost=0.00..2324610.84 rows=65222884 width=19)
>
>
>
> The last name (ln) and the year of birth (yb) is indexed, but that
> shouldn't matter because it's doing a sequential scan, correct? Am I
> running into the limitations of Postgres? We'd like to eventually get
I didn't see anything about your settings in postgresql.conf, but
increasing the sort_mem parameter may help that really expensive sort
step. I think the desired fix for this would probably be the TODO entry
on hash based aggregates but that's still in the future...
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-04-25 17:26:59 | Look for a French user to help here : Technique doc of PostgreSQL |
Previous Message | Lincoln Yeoh | 2002-04-25 16:38:49 | Strange vacuum error Was: No long-lived transaction, still can't delete tuples |