From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | holger(at)marzen(dot)de |
Cc: | David Griffiths <dgriffiths(at)boats(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Tuning/performance question. |
Date: | 2003-09-28 16:13:22 |
Message-ID: | 9442.1064765602@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Holger Marzen <holger(at)marzen(dot)de> writes:
> But many users compain about PostgreSQL's poor count(*) performance,
I don't think that's relevant here. Some other DB's have shortcuts for
determining the total number of rows in a single table, that is they can
do "SELECT COUNT(*) FROM a_table" quickly, but David's query is messy
enough that I can't believe anyone can actually do it without forming
the join result.
What I'd ask for is EXPLAIN ANALYZE output. Usually, if a complex query
is slower than it should be, it's because the planner is picking a bad
plan. So you need to look at how its estimates diverge from reality.
But plain EXPLAIN doesn't show the reality, only the estimates ...
David, could we see EXPLAIN ANALYZE for the query, and also the table
schemas (psql \d displays would do)? Also, please take it to
pgsql-performance, it's not really on-topic for pgsql-general.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-09-28 16:38:03 | Re: Rewriting pg_upgrade (was Re: State of Beta 2) |
Previous Message | Jim C. Nasby | 2003-09-28 16:01:49 | Re: Rewriting pg_upgrade (was Re: State of Beta 2) |
From | Date | Subject | |
---|---|---|---|
Next Message | David Griffiths | 2003-09-28 17:01:13 | Re: Tuning/performance question. |
Previous Message | Matt Clark | 2003-09-28 12:07:57 | Re: advice on raid controller |