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: | Raw Message | Whole Thread | 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? |