| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Gaetano Mendola <mendola(at)bigfoot(dot)com> |
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: using an index worst performances |
| Date: | 2004-08-20 01:39:41 |
| Message-ID: | 4125565D.3060008@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
>>> Without index: 1.140 ms
>>> With index: 1.400 ms
>>> With default_statistic_targer = 200: 1.800 ms
>>
>>
>>
>> Can I just check that 1.800ms means 1.8 secs (You're using . as the
>> thousands separator)?
>>
>> If it means 1.8ms then frankly the times are too short to mean
>> anything without running them 100 times and averaging.
>
>
>
> It mean 1.8 ms and that execution time is sticky to that value even
> with 1000 times.
Given the almost irrelvant difference in the speed of those queries, I'd
say that with the stats so high, postgres simply takes longer to check
the statistics to come to the same conclusion. ie. it has to loop over
200 rows instead of just 10.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gaetano Mendola | 2004-08-20 09:37:27 | Re: using an index worst performances |
| Previous Message | Gaetano Mendola | 2004-08-19 19:56:38 | Re: using an index worst performances |