Search Postgresql Archives

Re: query planner weirdness?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2008/6/28 Adam Rich <adam.r@xxxxxxxxxxxxx>:

> 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.

Yes, that's exactly what I mean.  I've already tried your suggestion (set enable_seqscan to off) with no luck.

Bob
 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux