Re: Performance Issues - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Performance Issues
Date
Msg-id 20020425093313.M65761-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Performance Issues  ("Shaun Grannis" <shaun_grannis@hotmail.com>)
List 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...



pgsql-general by date:

Previous
From: Lincoln Yeoh
Date:
Subject: Strange vacuum error Was: No long-lived transaction, still can't delete tuples
Next
From: "Andrey"
Date:
Subject: Re: How to deal with crashes?