| From: | Scott Ribe <scott_ribe(at)killerbytes(dot)com> |
|---|---|
| To: | Reg Me Please <regmeplease(at)gmail(dot)com>, "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com> |
| Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: [PGSQL 8.3.5] Use of a partial indexes |
| Date: | 2008-12-29 15:36:49 |
| Message-ID: | C57E3CA1.AC657%scott_ribe@killerbytes.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> The WHERE condition can be divided into a "slowly changing" part and in
> a "random" one. The random part is the one I change at every query to avoid
> result caching.
The first query will leave in cache at least many of the index pages needed
by the second query, and likely actual rows needed by the second query.
> Disk cache could explain the thing, but then why I got the high performances
> after the partial index has been created? By chance?
Creating the partial index reads rows, and the pages are left in the disk
cache. The only way to do proper comparisons is to reboot between trials in
order to compare queries with cold caches, or use the latter of multiple
runs in order to compare queries with hot caches.
--
Scott Ribe
scott_ribe(at)killerbytes(dot)com
http://www.killerbytes.com/
(303) 722-0567 voice
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2008-12-29 16:07:43 | Re: [PGSQL 8.3.5] Use of a partial indexes |
| Previous Message | Scott Marlowe | 2008-12-29 15:33:04 | Re: [PGSQL 8.3.5] Use of a partial indexes |