| From: | "Bob Duffey" <bobduffey68(at)gmail(dot)com> | 
|---|---|
| To: | "Adam Rich" <adam(dot)r(at)sbcglobal(dot)net> | 
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org | 
| Subject: | Re: query planner weirdness? | 
| Date: | 2008-06-28 05:00:43 | 
| Message-ID: | 14422aad0806272200j44f4df96q21d03c265490c655@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general | 
2008/6/28 Adam Rich <adam(dot)r(at)sbcglobal(dot)net>:
>
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2008-06-28 05:15:32 | Re: Advice Wanted on Selecting Multi-row Data Requests in 10-Row Blocks | 
| Previous Message | Adam Rich | 2008-06-28 04:53:00 | Re: query planner weirdness? |