Re: Performance Issues

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

In response to

Browse pgsql-general by date

  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