"Bob Duffey" <bobduffey68@xxxxxxxxx> writes:This is not wrong, or at least not obviously wrong. A full-table
> 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"
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 ...
Hi Tom,
Thanks for the reply. Is there some way I can provide evidence of the alternative being slower/faster? I guess that's my intuition, but since I can't figure out how to get postgres to use the alternative as the query plan, I can't test if it's slower!
Bob
