| From: | rihad <rihad(at)mail(dot)ru> |
|---|---|
| To: | Adam Rich <adam(dot)r(at)sbcglobal(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: index speed and failed expectations? |
| Date: | 2008-08-04 13:49:31 |
| Message-ID: | 489708EB.9000705@mail.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Adam Rich wrote:
>> This query from the console:
>>
>> select * from stats order by start_time;
>>
>> takes 8 seconds before starting its output. Am I wrong in assuming that
>> the index on start_time should make ORDER BY orders of magnitude
>> faster?
>> Or is this already fast enough? Or should I max up some memory (buffer)
>> setting to achieve greater speeds? Not that the speed is crucial, just
>> curious.
>>
>
> Postgresql won't use the index for queries like this. Due to the
> MVCC implementation, the index does not contain all necessary information
> and would therefore be slower than using the table data alone.
>
> (What postgresql lacks is a first_row/all_rows hint like oracle)
>
> However, if you limit the number of rows enough, you might force it
> to use an index:
>
> select * from stats order by start_time limit 1000;
>
Thanks! Since LIMIT/OFFSET is the typical usage pattern for a paginated
data set accessed from the Web (which is my case), it immediately
becomes a non-issue.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-08-04 13:52:38 | Re: bytea encode performance issues |
| Previous Message | Adam Rich | 2008-08-04 13:35:28 | Re: index speed and failed expectations? |