>
> "Bob Duffey" <[EMAIL PROTECTED]> 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
> ...
I think I understand what Bob's getting at when he mentions blocking.
The seqscan-and-sort would return the last record faster, but the
indexscan returns the first record faster. If you're iterating
through the records via a cursor, the indexscan behavior would be
more desirable. You could get the initial rows back without waiting
for all 130 million to be fetched and sorted.
In oracle, there is a first-rows vs. all-rows query hint for this sort
of thing.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
