Re: query planner weirdness? - Mailing list pgsql-general

From Tom Lane
Subject Re: query planner weirdness?
Date
Msg-id 17587.1214627771@sss.pgh.pa.us
Whole thread Raw
In response to query planner weirdness?  ("Bob Duffey" <bobduffey68@gmail.com>)
Responses Re: query planner weirdness?  ("Bob Duffey" <bobduffey68@gmail.com>)
Re: query planner weirdness?  ("Adam Rich" <adam.r@sbcglobal.net>)
List pgsql-general
"Bob Duffey" <bobduffey68@gmail.com> writes:
> I'm seeing some query plans that I'm not expecting.  The table in question
> is reasonably big (130,000,000 rows).  The table has a primary key, indexed
> by one field ("ID", of type bigint).  Thus, I would expect the following
> query to simply scan through the table using the primary key:

> select * from "T" order by "ID"

This is not wrong, or at least not obviously wrong.  A full-table
indexscan is often slower than seqscan-and-sort.  If the particular
case is wrong for you, you need to look at adjusting the planner's
cost parameters to match your environment.  But you didn't provide any
evidence that the chosen plan is actually worse than the alternative ...

            regards, tom lane

pgsql-general by date:

Previous
From: "Bob Duffey"
Date:
Subject: query planner weirdness?
Next
From: hubert depesz lubaczewski
Date:
Subject: Re: freebsd + postgresql 8.3.3 = 100% of cpu usage on stats collector?